Batch-Plan-Execute

Batch-Plan-Execute (Stapelweise Planung und Ausführung)

Verwenden Sie diesen Skill, wenn die Aufgabe darin besteht, Modulpläne und die daraus abgeleitete checklist.md basierend auf einer Anforderungsquelle und dem aktuellen Zustand des plans/-Verzeichnisses zu erstellen, zu überarbeiten, zu verwerfen, auszuführen oder zu überprüfen.

Dieser Skill hat derzeit diese expliziten Modi:

• plan: Erstellen oder Überarbeiten von implementierungsreifen Plänen und Aktualisieren der checklist.md
• execute: Umsetzen der bereits überprüften Pläne

Dieser Skill kann Folgendes tun:

• Akzeptiert Anforderungstext aus dem Chat, eine Anforderungsdatei wie requirements.md oder eine vorhandene Plan-Datei oder ein plans/-Verzeichnis.
• Rekonstruiert den aktuellen Planungszustand aus der neuesten Anforderungsquelle, vorhandenen Plan-Dateien und einer versteckten Zustandsdatei.
• Erkennt gemischte Änderungen pro Modul: neue Anforderungen, geänderte Anforderungen, entfernte Anforderungen und Überprüfungsnotizen.
• Erstellt abhängigkeitsbewusste Modul- oder Arbeitsstrompläne, die parallelisierbare und serielle Arbeiten abbilden.
• Generiert eine konsolidierte checklist.md aus der neuesten Anforderungsquelle plus autoritativen Überprüfungsnotizen.
• Führt genehmigte Pläne mit Implementierungs-Subagenten nur nach einem expliziten Ausführungsbefehl des Benutzers aus.

Eingabeverarbeitung

Wählen Sie die primäre Eingabe in dieser Reihenfolge:

1. Ein expliziter Plan-Dateipfad oder plans/-Verzeichnispfad, der vom Benutzer genannt wurde.
2. Ein expliziter Anforderungsdateipfad, der vom Benutzer genannt wurde.
3. Eine Datei oder ein Dokument, das bereits im Aufgabenkontext angehängt ist.
4. Der Anforderungstext, der direkt im Chat geschrieben wurde.

Verwenden Sie diese Regeln:

• Wenn ein Plan-Dateipfad angegeben wird, behandeln Sie diese Plan-Linie als primären Ausgangspunkt und überprüfen Sie das benachbarte plans/-Verzeichnis.
• Wenn ein plans/-Verzeichnispfad angegeben wird, überprüfen Sie nur die Plan-Dateien und die Zustandsdatei in diesem Verzeichnis.
• Wenn ein Anforderungsdateipfad angegeben wird, lesen Sie diese direkt und behandeln Sie sie als neueste Anforderungsquelle.
• Wenn die Eingabe roher Chat-Text ist, behandeln Sie den gesamten Benutzertext als neueste Anforderungsquelle.
• Wenn sowohl eine Anforderungsquelle als auch ein plans/-Verzeichnis verfügbar sind, verwenden Sie immer beide.

Schlagen Sie sofort fehl, wenn eine referenzierte Datei oder ein referenziertes Verzeichnis nicht existiert oder nicht lesbar ist.

Ausgabesprache

Verwenden Sie diese Regeln:

• Passen Sie die gesamte benutzersichtbare Ausgabesprache an die dominante Sprache der neuesten Anforderungsquelle an.
• Wenn keine Anforderungsquelle existiert, passen Sie die Sprache an die dominante Sprache der aktuellen Benutzereingabe an.
• Wenn der Benutzer explizit nach einer Übersetzung oder einer bestimmten Ausgabesprache fragt, folgen Sie stattdessen dieser.

Modusauswahl

Standardmäßig wird der plan-Modus verwendet.

Wechseln Sie nur dann in den execute-Modus, wenn der Benutzer in der aktuellen Runde explizit einen Ausführungsbefehl gibt.

Beispiele, die definitiv zum execute-Modus führen:

• 开始执行 (Beginne mit der Ausführung)
• 按这个方案实现 (Setze diesen Plan um)
• 去改代码 (Ändere den Code)
• 直接落地 (Setze es direkt um)
• implement now
• apply the plan

Beispiele, die den Modus NICHT vom Standard-plan-Verhalten ändern:

• LGTM
• OK
• 继续 (Mach weiter)
• 按这个方向 (In diese Richtung)
• review 过了 (Wurde bereits überprüft)
• jede Zustimmung, die den Plan bestätigt, aber nicht explizit die Implementierung starten möchte

Verwenden Sie diese Regeln:

• Die Zustimmung zur Überprüfung ist keine Zustimmung zur Ausführung.
• Wenn der Benutzer mehrdeutig ist, bleiben Sie im plan-Modus und verfeinern Sie entweder den Ausführungsplan oder fragen Sie nach einem klareren Ausführungsbefehl.
• Leiten Sie niemals eine Ausführungsabsicht aus Dynamik, Optimismus oder fehlenden Einwänden ab.

Ausgabeort und Benennung

Schreiben Sie Plan-Dateien in ein plans/-Verzeichnis:

• Wenn die Quelle eine Anforderungsdatei ist, verwenden Sie einen plans/-Ordner neben dieser Datei.
• Wenn die Quelle eine Plan-Datei oder ein plans/-Verzeichnis ist, schreiben Sie weiterhin in dasselbe plans/-Verzeichnis.
• Wenn die Quelle roher Chat-Text ist, verwenden Sie <cwd>/plans/.

Erstellen Sie das plans/-Verzeichnis, wenn es nicht existiert.

Basis-Plan-Dateien verwenden dieses Format:

• <modul-slug>.md

Überarbeitungs-Plan-Dateien verwenden dieses Format:

• <modul-slug>.rev-<n>.md

Die abgeleitete Checklisten-Datei muss sein:

• checklist.md

Die versteckte Zustandsdatei muss sein:

• .state.json

Verwenden Sie diese Benennungsregeln:

• new-plan kann eine Basisdatei erstellen, wenn das Modul keine Vorgänger-Linie hat.
• revise-plan und obsolete-plan müssen immer eine neue rev-Datei schreiben.
• no-op darf keine neue Plan-Datei schreiben.
• Überschreiben Sie keine vorhandene Datei stillschweigend.
• Plan-Slugs sollten der Implementierungsverantwortung folgen, nicht dem Text der Anforderungsüberschrift, wenn diese beiden unterschiedlich sind.
• Wenn die neueste Anforderungsquelle eine lesbare Datei ist, schreiben Sie checklist.md neben diese Anforderungsdatei anstatt in plans/.
• Wenn keine lesbare Anforderungsdatei existiert, schreiben Sie checklist.md stattdessen in das aktive plans/-Verzeichnis.
• Überschreiben Sie immer den aufgelösten checklist.md-Pfad, wenn er sicher aktualisiert werden kann.
• checklist.md ist ein abgeleiteter Schnappschuss, kein Artefakt der Plan-Linie und kein Ausführungsziel.

Zustandsdatei

Verwalten Sie plans/.state.json als Planungsbasis.

Die Zustandsdatei muss mindestens enthalten:

• requirement_source
• requirement_hash
• run_at
• modules

Jedes Modulzustandsobjekt muss mindestens enthalten:

• slug
• title
• status
• source_excerpt_hash
• body_hash_without_heading
• latest_plan_file
• latest_rev
• last_action

Statuswerte müssen explizit sein:

• active (aktiv)
• obsolete (veraltet)

Verwenden Sie diese Regeln:

• Die Zustandsdatei beschreibt nur die Planungslinie.
• Behandeln Sie die Zustandsdatei nicht als Berechtigung zur Ausführung.
• Wenn die Zustandsdatei fehlt, starten Sie stattdessen von der neuesten Anforderungsquelle und den vorhandenen Plan-Dateien, anstatt zu scheitern.

Plan-Modus

Verwenden Sie docs/plan.md als detaillierten Vertrag zum Schreiben von Plänen.

Modulextraktion

Standardmäßig wird nach Implementierungseinheiten und Abhängigkeitsgrenzen aufgeteilt, nicht nach Repository-Paketstruktur und nicht mechanisch nach Anforderungsüberschriften.

Vor dem Extrahieren von Modulen oder dem Berechnen von Anforderungs-Hashes verarbeiten Sie die neueste Anforderungsquelle vor, indem Sie HTML-Kommentare außerhalb von Code-Blöcken entfernen.

Verwenden Sie diese Regeln:

• Behandeln Sie kommentierten Anforderungsinhalt als nicht existent.
• Beginnen Sie nur als Extraktionshilfe mit den Anforderungsabschnitten, nicht als endgültige Modulgrenze.
• Behandeln Sie Meta-Abschnitte wie Hintergrund, Ziele, Umfang, Nicht-Ziele, Annahmen, Rollout, Abnahmekriterien und nicht-funktionale Anforderungen als globale Einschränkungen, nicht als eigenständige Module.
• Führen Sie Anforderungsteile zusammen, die auf demselben Implementierungspfad, der gemeinsamen Code-Oberfläche oder dem gleichen deliverable auf Eigentümerebene landen.
• Teilen Sie einen Abschnitt nur, wenn er eindeutig unabhängige Ergebnisse oder eine strikte Implementierungsreihenfolge wie Vorarbeiten vor Feature-Arbeiten beschreibt.
• Bevorzugen Sie Modulgrenzen, die mit funktionaler Verantwortung, gemeinsamer Schnittstellenverantwortung, Migrationsgrenzen oder Bereitstellungsgrenzen übereinstimmen.
• Erstellen Sie keine überlappenden Module, die beide dieselbe gemeinsame Änderung besitzen.
• Scheitern Sie lautstark, wenn keine implementierungstragenden Module extrahiert werden können oder die gemeinsame Verantwortung nicht klar zugewiesen werden kann.

Wenn die Quelle ein einfacher Text ohne zuverlässige Überschriften ist:

• leiten Sie eine prägnante Modulliste aus dem Anforderungsinhalt ab
• verwenden Sie Feature-Grenzen, Workflows, Ergebnisse und Voraussetzungsbeziehungen als Modulnamen
• vermeiden Sie generische Modulnamen wie misc, other oder supporting-work

Modellierung von Abhängigkeiten und Parallelität

Nach dem Extrahieren der Kandidatenmodule leiten Sie einen expliziten Abhängigkeitsgraphen ab, bevor Sie klassifizieren oder Subagenten starten.

Verwenden Sie diese Regeln:

• Klassifizieren Sie jedes Modul als foundation (Grundlage), feature (Feature) oder follow-on (Nachfolger).
• Notieren Sie depends_on (abhängig von), blocks (blockiert), parallelizable_with (parallelisierbar mit) und shared_change_owner (gemeinsamer Änderungseigentümer).
• Bevorzugen Sie parallele Module nur, wenn sie nicht dieselbe gemeinsame Code-Verantwortung in derselben Phase erfordern.
• Bevorzugen Sie serielle Abfolge, wenn ein Modul Verträge, Schemata, Migrationen oder gemeinsam genutzte Dienstprogramme ändert, die ein anderes Modul konsumiert.
• Wenn die Implementierung A dann B ist, modellieren Sie das direkt, anstatt beide in eine Peer-Liste zu zwingen.
• Nehmen Sie keine falsche Parallelität an. Sequenzieren Sie konservativ, wenn die sichere Reihenfolge unklar ist.

Erkennung von Überprüfungen und Linie

Die Erkennung von Überprüfungen ist nur innerhalb von plans/*.md sinnvoll.

Verwenden Sie diese Regeln:

• Behandeln Sie jeden HTML-Kommentar außerhalb von Code-Blöcken als Überprüfungsnotiz.
• Wenn der Überprüfungsinhalt in Benutzerkommentaren mit dem ursprünglichen Anforderungsdokument in Konflikt steht, behandeln Sie den Überprüfungsinhalt als die neueste maßgebliche Anweisung.
• Bewahren Sie keine HTML-Kommentare in der endgültigen Planausgabe auf.
• Lösen Sie das neueste Linien-Artefakt durch die höchste rev auf, ansonsten die neueste Basisdatei.
• Bevorzugen Sie zuerst Slug-Übereinstimmungen.
• Erlauben Sie Umbenennungsabgleiche nur für sichere Eins-zu-eins-Übereinstimmungen bei body_hash_without_heading.
• Wenn der Umbenennungsabgleich mehrdeutig ist, raten Sie nicht.

Checklisten-Generierung

Generieren oder aktualisieren Sie checklist.md bei jedem erfolgreichen plan-Lauf.

Verwenden Sie diese Regeln:

• Erstellen Sie die Checkliste aus der neuesten Anforderungsquelle plus den maßgeblichen Überprüfungsnotizen aus der neuesten Plan-Linie.
• Wenden Sie dieselbe Anforderungsvorverarbeitung an, die für die Modulextraktion verwendet wird, bevor Sie Checklisten-Items ableiten.
• Behandeln Sie Überprüfungskommentare als maßgeblich, wenn sie mit dem ursprünglichen Anforderungsdokument in Konflikt stehen.
• Bewahren Sie niemals rohe HTML-Kommentare in checklist.md auf; bewahren Sie nur deren aufgelöste Absicht.
• Organisieren Sie Checklistenabschnitte nach Abhängigkeitsebene und Modulreihenfolge, nicht nach der rohen Reihenfolge der Anforderungsüberschriften.
• Verwenden Sie Markdown-Überschriften plus umsetzbare, nicht abgehakte Items wie - [ ] ....
• Bevorzugen Sie überprüfbare Implementierungs- oder Abnahmeergebnisse, keine erzählenden Zusammenfassungen.
• Wenn die neueste Anforderungsquelle eine lesbare Datei ist, schreiben Sie checklist.md neben diese Anforderungsdatei.
• Wenn keine lesbare Anforderungsdatei existiert, schreiben Sie checklist.md in das aktive plans/-Verzeichnis.
• Wenn die Quelle eine Plan-Datei oder ein plans/-Verzeichnis ist, lösen Sie die neueste lesbare Anforderungsquelle aus plans/.state.json auf, bevor Sie die Checkliste aktualisieren.
• Wenn eine Anforderungsquelle nicht sicher rekonstruiert werden kann, erlauben Sie überprüfungsgesteuerte Planrevisionen, berichten Sie jedoch, dass checklist.md nicht aktualisiert werden konnte.

Klassifizierung im gemischten Modus

Bestimmen Sie die Aktion pro Modul, nicht einmal für den gesamten Durchlauf.

Klassifizieren Sie jedes Modul in genau eine Aktion:

• new-plan (Neuer Plan)
• revise-plan (Plan überarbeiten)
• obsolete-plan (Plan für veraltet erklären)
• no-op (Keine Operation)

Verwenden Sie diese Standardeinstellungen:

• Führen Sie Anforderungsänderungen und Überprüfungsnotizen in einem revise-plan zusammen.
• Generieren Sie eine obsolete-plan-Revision, anstatt entfernte Module stillschweigend fallen zu lassen.
• Wenn keine Anforderungsquelle verfügbar ist, erlauben Sie nur überprüfungsgesteuerte Revisionen.
• Nur-Kommentar-Bearbeitungen in der Anforderungsquelle dürfen kein revise-plan auslösen.

Plan-Subagenten

Starten Sie einen Planungs-Subagenten pro betroffenem Modul, nachdem die Modulliste, der Abhängigkeitsgraph und die Aktion festgelegt wurden.

Verwenden Sie diese Regeln:

• Bevorzugen Sie schreibgeschützte Analyse-Subagenten für die Planungsarbeit.
• Verwenden Sie einen Allzweck-Subagenten nur, wenn keine dedizierte schreibgeschützte Analyse-Rolle verfügbar ist und der Subagent dennoch schreibgeschützt bleiben kann.
• Planungs-Subagenten dürfen keine Dateien bearbeiten.
• Führen Sie Planungs-Subagenten nur innerhalb derselben Abhängigkeitsebene parallel aus.
• Bitten Sie jeden Planungs-Subagenten, betroffene Codebereiche, Schnittstellen, Abhängigkeiten, Parallelitätshinweise, Risiken, Tests und explizite Annahmen zurückzugeben.

Planzusammenstellung

Der Hauptagent ist für die endgültige Planqualität, die Plan-Dateiausgabe und die Aktualisierungen der Zustandsdatei verantwortlich.

Verwenden Sie diese Regeln:

• Lösen Sie modulübergreifende Abhängigkeiten auf, sodass Terminologie und gemeinsame Änderungen konsistent bleiben.
• Bestätigen Sie einen klaren Eigentümer für jede gemeinsam genutzte Schnittstelle, jedes Schema, jede Migration oder Infrastrukturänderung.
• Ordnen Sie die endgültige Modulausgabe nach Abhängigkeitsebenen an, nicht nach der Reihenfolge der Anforderungsüberschriften.
• Geben Sie explizit an, wann ein Modul durch ein anderes Modul blockiert ist oder nach Voraussetzungen parallel ausgeführt werden kann.
• Aktualisieren Sie checklist.md, nachdem die Modulpläne zusammengestellt wurden und bevor die Zustandsdatei aktualisiert wird.
• Aktualisieren Sie plans/.state.json erst, nachdem alle betroffenen Module verarbeitet wurden.

Ausführungsmodus

Verwenden Sie docs/execute.md als detaillierten Ausführungsvertrag.

Ausführungsvoraussetzungen

Schlagen Sie sofort fehl, wenn eine dieser Bedingungen zutrifft:

• Keine Ziel-Plan-Datei oder kein plans/-Verzeichnis kann aufgelöst werden.
• Das neueste Ziel-Plan-Artefakt enthält noch nicht aufgelöste Überprüfungskommentare.
• Das Repository kann nicht ausreichend verankert werden, um die Schreibverantwortung sicher zuzuweisen.
• Die Verantwortung für gemeinsame Änderungen ist mehrdeutig.
• Abhängigkeitszyklen können nicht als ein zusammengeführtes Modul gerechtfertigt werden.

Ausführungsregeln

Nachdem die Hürde und die Voraussetzungen erfüllt sind:

• Verwenden Sie docs/execute.md für die Zielauflösung, Verankerung, Worker-Verteilung, Integration, Verifizierung und Fertigstellung.
• Führen Sie das neueste überprüfte Artefakt für jede ausgewählte Modullinie aus.
• Respektieren Sie den im Plan-Modus erstellten Abhängigkeitsgraphen oder rekonstruieren Sie ihn aus der neuesten Plansammlung vor der Verteilung.

Fehlerregeln

Stoppen Sie und melden Sie das Problem, anstatt schwache Ausgabe zu generieren, wenn:

• die Anforderungsdatei, die Plan-Datei oder das plans-Verzeichnis fehlt oder nicht lesbar ist.
• die Modulextraktion für eine erforderliche Anforderungsquelle fehlschlägt.
• ein Plan größtenteils Spekulation wäre, ohne sinnvolle Einbindung der Codebasis.
• mehrere Kandidaten für die neueste Linie für ein Modul existieren und die Reihenfolge nicht sicher aufgelöst werden kann.
• der Umbenennungsabgleich mehrdeutig ist und nicht auf eine sichere Eins-zu-eins-Zuordnung reduziert werden kann.
• gemeinsame Änderungen oder Abhängigkeitsverantwortung nicht einem klaren Modul oder Arbeitsstrom zugewiesen werden können.
• der Abhängigkeitsgraph Zyklen enthält, die nicht als ein einzelnes zusammengeführtes Modul gerechtfertigt werden können.
• die Zustandsdatei existiert, aber fehlerhaft ist und nicht sicher aus sichtbaren Artefakten rekonstruiert werden kann.

Geben Sie keine leeren Plan-Dateien, zusammenfassungsorientierte Dateien oder einen einzelnen aggregierten Plan aus, wenn die Aufgabe Ausgaben pro Modul erfordert.