steve-swanson/execute-work

Arbeit ausführen

Die vereinbarte Arbeit autonom auf einem aussagekräftigen Branch aus develop ausführen. Implementierung an Unteragenten in separaten Worktrees delegieren, dann deren abgeschlossene Branches per Fast-Forward in diesen koordinierenden Branch integrieren, aufräumen und einen Pull-Request zur Überprüfung aus dem abgeschlossenen koordinierenden Branch in develop öffnen.

Der Aufruf autorisiert lokale Aufgabenbranches, Worktrees, Commits, Rebasing eigener unveröffentlichter Aufgabenbranches, Fast-Forward-Merges in den koordinierenden Branch, Entfernung von sauberen, vollständig integrierten Aufgaben-Worktrees und -Branches, Pushen des abgeschlossenen koordinierenden Branches und Erstellen seines PRs in develop. Ohne weitere Bestätigung für diese Aktionen fortfahren. Den Umfang des Benutzers und die Repository-Anweisungen befolgen, einschließlich eines expliziten lokalen oder kein-PR-Overrides. Das Mergen des PRs und das Deployment liegen außerhalb der Autorisierung dieses Skills. Bestehende Verbote in Kraft lassen.

1. Den koordinierenden Branch vorbereiten

Den vereinbarten Plan, die zutreffende AGENTS.md und die erforderlichen Projektanleitungen lesen. Wenn die Arbeit bereits definiert ist, ohne eine weitere Design- oder Genehmigungsrunde ausführen. Nur eine konzentrierte Frage für eine wesentliche fehlende Anforderung stellen.

Status, Refs und vorhandene Worktrees prüfen. Nicht zusammenhängende Bearbeitungen und Checkouts erhalten; sie nicht zurücksetzen, stashen oder zweckentfremden. develop von seinem konfigurierten Remote holen, wenn verfügbar, und diesen geholten Stand verwenden. Wenn das Holen nicht verfügbar ist, die Einschränkung offenlegen und eine vorhandene lokale develop-Ref verwenden; wenn keines existiert, nach der Basis fragen. Niemals stillschweigend einen anderen Branch substituieren.

Vor dem Erstellen eines Branches oder Worktrees git worktree list --porcelain, lokale Branch-Namen und verwaltete Worktree-Anhänge erfassen, sofern verfügbar. Ein laufzeiteigenes Inventar in der Aufgabencheckliste führen: Branch, absoluter Pfad, Besitzer/Agent, Verwaltungstyp und -identität, letzter Commit und Bereinigungsstatus. Jede Aufgabe, jeden Helfer, Reviewer, Wiederholung und jede Nachkommen-Agent-Checkout, die für diesen Lauf erstellt wurden, einschließen, selbst wenn sie verworfen wurden oder keine Änderungen enthalten. Der Koordinator ist für die Bereinigung dieses gesamten Inventars verantwortlich. Vorhandene und nicht zusammenhängende Branches/Worktrees erhalten; ein passendes Namenspräfix ist kein Eigentumsnachweis.

Einen dedizierten koordinierenden Worktree und Branch erstellen. Mit dem konventionellen Branch-Stil benennen, <type>/<short-description>, Kleinbuchstaben mit Bindestrichen, wie feat/store-invitation-recovery. Den Typ wählen, der zur Arbeit passt: feat (neues Verhalten), fix (Fehlerbehebung), refactor, perf, docs, test, chore (Tooling oder Wartung) oder ci. Wenn der Benutzer oder das Repository eine andere Konvention nennt (z. B. in AGENTS.md), dieser folgen. integration nicht in den Namen aufnehmen. Den koordinierenden Basis-Commit aufzeichnen. Bei einem fortgesetzten Aufruf den koordinierenden Branch/Worktree und das Inventar dieses Laufs wiederverwenden, ihren Zustand prüfen, anstatt neu zu starten.

2. Aufteilen und delegieren

Nach Liefergegenstand und Dateibesitz aufteilen. Unabhängige Aufgaben gleichzeitig innerhalb der verfügbaren Agentenkapazität ausführen; Abhängigkeiten und sich überschneidende Bearbeitungen sequenzieren. Jeden Aufgabenbranch/Worktree vom aktuellen Stand des koordinierenden Branches aus erstellen. Nachdem eine Abhängigkeit integriert wurde, abhängige Aufgaben vom aktualisierten Stand aus starten.

Tatsächliche Unteragenten mit den Aufgabenanforderungen, relevanten Planabschnitten, absolutem Worktree-Pfad, Branch, eigenen Dateien, Abhängigkeitsverträgen, Akzeptanzkriterien und erforderlichen Prüfungen starten. Jeder Agent arbeitet nur in seinem zugewiesenen Checkout, committed seine Änderungen und meldet seinen Commit, Prüfungen, verbleibende Bedenken und alle zusätzlichen Branches/Worktrees, die er erstellt hat. Diese sofort im laufzeiteigenen Inventar registrieren. Der Koordinator allein integriert und entfernt Worktrees. Unteragenten dürfen diesen Orchestrierungsskill nicht rekursiv aufrufen oder ihre Branches pushen. Explizite Arbeitsverzeichnisse oder git -C verwenden; Agenten können ein gemeinsames Standardverzeichnis nutzen. Wenn Delegierung nicht verfügbar ist, diese Einschränkung melden, anstatt stillschweigend Solo-Ausführung zu substituieren.

3. Abgeschlossene Aufgaben überprüfen

Den tatsächlichen Diff und die Commits jeder Aufgabe gegen ihre Akzeptanzkriterien prüfen. Fehler mit dem besitzenden Agenten ansprechen. Einen sauberen Aufgaben-Checkout, abgeschlossene Commits und relevante bestandene Prüfungen vor der Integration verlangen; vorhandene oder umweltbedingte Blockierer genau melden. Arbeit nicht lediglich mergen, weil ein Agent die Fertigstellung meldet.

4. Seriell mit Fast-Forward-Merges integrieren

Schreibzugriffe auf einen abgeschlossenen Aufgabenbranch stoppen, bevor er rebased wird. Für jede Aufgabe die Abstammung gegen den aktuellen Stand des koordinierenden Branches prüfen. Parallele Geschwisterbranches divergieren nach dem ersten Merge: Jeden verbleibenden unveröffentlichten Aufgabenbranch auf den aktualisierten koordinierenden Branch rebasen, bevor gemergt wird. Konflikte gegen die vereinbarten Anforderungen auflösen, bereits integriertes Verhalten erhalten; betroffene Prüfungen nach dem Rebasing oder der Konfliktlösung erneut ausführen.

Beispiel unter Verwendung der aufgezeichneten absoluten Pfade und Branch-Namen:

git -C "$task_path" rebase "$work_branch"
git -C "$task_path" status --short
# Die erforderlichen Prüfungen in task_path ausführen, dann Abstammung überprüfen.
git -C "$work_path" merge-base --is-ancestor HEAD "$task_branch"
git -C "$work_path" merge --ff-only "$task_branch"

Das Ergebnis jedes Befehls prüfen, bevor fortgefahren wird. Wenn Fast-Forward fehlschlägt, die Abstammung erneut prüfen und bei Bedarf erneut rebasen. Keinen Merge-Commit, Squash, Cherry-Pick, Force-Push oder Reset des koordinierenden Branches substituieren. Wenn eine sichere Lösung eine Produktentscheidung erfordert, beide Branches behalten und fragen. Nach jeder erfolgreichen Aufgabenintegration und deren erforderlichen Prüfungen die erforderliche Bereinigung für diese Aufgabe sofort durchführen. Die kombinierte Arbeit vom koordinierenden Checkout aus überprüfen; gemergte Aufgaben-Checkouts sind für die PR-Überprüfung nicht erforderlich. Dieselbe Bereinigung auf verworfene oder ersetzte laufzeiteigene Helfer anwenden, sobald deren Arbeit berücksichtigt wurde.

5. Überprüfen, aufräumen und den PR öffnen

Die relevanten kombinierten Prüfungen auf dem endgültigen koordinierenden Branch ausführen und das Ergebnis mit dem gesamten Plan abgleichen. Integrationsregressionen vor dem Abschluss beheben.

Erforderliche Bereinigung: Ausführen und überprüfen

Bereinigung ist Teil des Liefergegenstands, kein Vorschlag für den Benutzer, diese später durchzuführen. Der Aufruf autorisiert bereits die Entfernung der sauberen, vollständig integrierten Aufgaben-/Helfer-Worktrees und -Branches dieses Laufs; nicht erneut um diese Entfernungen bitten.

1. Den besitzenden Agenten und alle Hintergrundprozesse stoppen, die in den Checkout schreiben. Den endgültigen Commit des Branches nach dem Rebasing aufzeichnen, überprüfen, ob er ein Vorfahre des aktuellen koordinierenden Stands ist, und getrackte, ungetrackte und ignorierte Dateien prüfen. Bei einem Helfer ohne Commits überprüfen, ob sein Stand bereits enthalten ist. Unfertige Arbeit mit dem Besitzer klären: erforderliche Änderungen integrieren und wertvolle lokale Artefakte an einem aufbewahrten Ort behalten, bevor fortgefahren wird. Wegwerfbare laufzeitgenerierte Caches oder Logs können durch genauen Pfad entfernt werden; sie sind kein Grund, einen ansonsten fertigen Checkout auf unbestimmte Zeit zu belassen.

2. Für einen einfachen Git-Worktree diese Operationen mit den aufgezeichneten genauen Pfaden und Namen ausführen, jedes Ergebnis prüfen, bevor fortgefahren wird:

   git -C "$work_path" merge-base --is-ancestor "$task_tip" "$work_branch"
   git -C "$task_path" status --porcelain --untracked-files=all
   git -C "$work_path" worktree remove "$task_path"
   git -C "$work_path" branch -d "$task_branch"
   

   Eine Worktree-Entfernung löscht nicht seinen Branch. Beide Operationen sind erforderlich. Auch laufzeiteigene Branches ohne verbleibenden Worktree löschen. Niemals Force-Removal, git branch -D, breite Verzeichnislöschung oder Verwerfen unbekannter Bearbeitungen verwenden. Fehlgeschlagene Befehle diagnostizieren und gewöhnliche Bereinigungsprobleme im Rahmen beheben, anstatt sie stillschweigend zu überspringen.

3. Bei einem app-verwalteten Worktree dessen Verwaltungs-API anstelle der direkten Verzeichnislöschung verwenden. In Codex list_artifacts verwenden, um die genaue besitzende Worktree-Identität aufzulösen, dann archive_worktree; das Ergebnis prüfen und erneut auflisten, um zu bestätigen, dass es nicht mehr aktiv ist. Den laufzeiteigenen lokalen Branch danach mit git branch -d löschen, sofern er noch vorhanden ist. Ein Archiv-Snapshot oder App-Anhang ersetzt nicht die Überprüfung sowohl der Git-Registrierung als auch der Branch-Löschung.

4. Einen Inventareintrag erst als bereinigt markieren, nachdem überprüft wurde, dass sein genauer Pfad nicht vorhanden ist, er nicht mehr von git worktree list --porcelain registriert ist, sein Branch in lokalen Refs fehlt und ein verwalteter Anhang nicht mehr aktiv ist. Andere Checkouts prüfen, wenn Git sagt, dass der Branch noch ausgecheckt ist. Eine erfolgreiche Entfernungsanforderung oder den Bericht eines Agenten nicht als Nachweis behandeln.

5. Unmittelbar vor der endgültigen Antwort, nach der PR-Erstellung oder Nacharbeit, die Git-Branch/Worktree- und verwalteten Anhang-Inventare erneut erfassen. Sie mit der Basislinie und dem laufzeiteigenen Inventar vergleichen; neue Einträge, die in Agentenberichten fehlen, berücksichtigen, ohne nicht zusammenhängende gleichzeitige Arbeit zu löschen. Der koordinierende Branch/Worktree muss der einzige verbleibende laufzeiteigene Branch/Worktree sein. Ihn für den PR und Tests aufbewahren, zusammen mit vorhandenen oder nicht zusammenhängenden Checkouts. Diese abschließende Prüfung ist erforderlich, auch wenn die PR-Erstellung blockiert oder übersprungen wird, und bei Fehler/Unterbrechung vor der Übergabe, wenn sicher möglich.

Wenn die Bereinigung nicht sicher abgeschlossen werden kann, weiterhin andere berechtigte Einträge bereinigen und Bereinigung blockiert melden, mit jedem aufbewahrten Branch/Pfad, der fehlgeschlagenen Operation oder wertvollen/nicht gemergten Arbeit und der kleinsten Aktion, die zur Lösung erforderlich ist. Den Gesamt-Workflow nicht als abgeschlossen melden, während laufzeiteigene temporäre Branches/Worktrees verbleiben. An der routinemäßigen Bereinigung weiterarbeiten, anstatt bei einem erfolgreichen Merge, bestandenen Tests oder der PR-Erstellung zu enden.

Pushen und den PR öffnen

Den koordinierenden Branch/Worktree mit der gesamten committed Arbeit zur Überprüfung bereithalten. Nach erfolgreicher Integration und erforderlicher Validierung den endgültigen Diff prüfen und nur den koordinierenden Branch in das vorgesehene Repository-Remote pushen. Einen zur Überprüfung bereiten PR mit develop als Basis und dem koordinierenden Branch als Head erstellen; nur einen Entwurf verwenden, wenn der Benutzer dies explizit anfordert. Vor der Erstellung auf einen vorhandenen offenen PR für dieses Head/Base prüfen, auch nach einem unsicheren Erstellungsresultat, und ihn wiederverwenden oder aktualisieren, anstatt ein Duplikat zu erstellen.

Den Repository-PR-Vorlagen, Betreffzeilen-Konventionen und Ticket-Link-Anforderungen folgen. Das endgültige Verhalten, Prüfungen und deren Ergebnisse sowie konkrete manuelle Tests beschreiben. Diese Schritte müssen das Testen des Produkts und/oder die Überprüfung des persistenten Zustands beschreiben, nicht eine weitere Liste von Repository-Testbefehlen. Lokales Git für den Push und einen verfügbaren Repository-Connector für die PR-Erstellung bevorzugen; bei Bedarf ein authentifiziertes CLI verwenden. Die tatsächliche Basis, den Head und den veröffentlichten Commit des PRs gegen den abgeschlossenen koordinierenden Branch überprüfen. Jeden erstellten PR an den aktuellen Chat anhängen, wenn das Artefakt-Anhang-Tool verfügbar ist. Den PR zur Überprüfung offen lassen.

Wenn das Pushen oder die PR-Erstellung blockiert ist, den abgeschlossenen koordinierenden Branch/Worktree aufbewahren und den genauen Blockierer sowie die verbleibende Aktion melden. Nicht behaupten, dass ein PR existiert, ohne eine bestätigte URL, oder einen Force-Push durchführen, um eine Ablehnung zu umgehen.

Abschlussbericht

Die endgültige Antwort muss mit dem exakten Namen des koordinierenden Branches und dem absoluten Worktree-Pfad beginnen. Einen Markdown-Link zum bestätigten PR oder den Grund, warum die PR-Erstellung blockiert oder explizit übersprungen wird, einschließen, dann Folgendes einschließen:

• Was jetzt funktioniert: Das abgeschlossene Verhalten und der verbleibende Umfang.
• Bereits ausgeführte Prüfungen: Exakte Befehle und tatsächliche Ergebnisse, wobei übersprungene oder blockierte Prüfungen identifiziert werden.
• So testen: Eine kurze nummerierte, vom Benutzer ausführbare Validierungsprozedur vom koordinierenden Worktree aus. Diese ist von automatischen Prüfungen getrennt und darf nicht durch Wiederholen von pnpm test, Lint, Build oder ähnlichen Befehlen erfüllt werden. Gegebenenfalls einschließen:
  • Einrichtung: Umgebung/App-URL, Login und Rolle, Dienste, Seed- oder Fixture-Daten, Datensatz-IDs und das Arbeitsverzeichnis;
  • Der Hauptproduktablauf: Exakter Bildschirm oder Endpunkt, realistische Eingaben und UI-Aktionen, das auszulösende Verhalten und das erwartete sichtbare Ergebnis;
  • Relevante Rand- oder Regressionsabläufe: Ungültige, leere, doppelte, eingeschränkte oder zuvor abgeschlossene Daten, wenn diese Fälle relevant sind;
  • Überprüfung des persistenten Zustands für Änderungen, die Daten schreiben oder übertragen: Eine schreibgeschützte DB/API-Prüfung mit der Tabelle oder Ressource, Filtern oder Identifikatoren, zu prüfenden Feldern/Status und dem erwarteten Ergebnis bereitstellen. Die Benutzeraktion mit dem gespeicherten Datensatz verbinden, anstatt lediglich „die DB prüfen“ zu sagen. Beispielsweise sollte eine Prospecting-Änderung sagen, einen Territory-Scan für ein benanntes Gebiet und einen Radius zu erstellen, einen bestimmten Ort zu finden, sein erforderliches Attribut zu bestätigen, die Überprüfungs-/Outreach-Aktion abzuschließen und den resultierenden Überprüfungs- oder Outreach-Status in der App und in relevanten Datensätzen zu überprüfen. Dieselbe Spezifität für andere Produkt-Workflows verwenden. Automatisierte Befehle unter Bereits ausgeführte Prüfungen belassen. Jeden manuellen Schritt als durchgeführt oder vorgeschlagen markieren; wenn die App oder Datenbank nicht verfügbar war, den genauen Blockierer und die kleinste Einrichtung nennen, die zum Ausführen erforderlich ist. Datenbankprüfung ist schreibgeschützt, es sei denn, die genehmigte Arbeit autorisiert explizit die Mutation von Testdaten.
• Bereinigung und Blockierer: Überprüfte Anzahl der entfernten oder archivierten temporären Worktrees und der gelöschten lokalen Branches; der verbleibende laufzeiteigene Branch/Worktree in der abschließenden Prüfung (normalerweise nur der Koordinator). Jeden blockierten temporären Branch/Pfad und seinen genauen Grund auflisten; alle unvollständigen Push- oder PR-Schritte einschließen.

Fortschrittsaktualisierungen präzise halten und mit einer konkreten nächsten Aktion abschließen, die in unter zwei Minuten durchführbar ist.