worktrees-hives

worktrees-hives Skill

Installierbarer Agent-Skill für den worktrees-hives Hybrid-Orchestrator.

Wann verwenden

Verwenden Sie diesen Skill, wenn:

• Sie Arbeit aus GitHub- oder Linear-Issues entdecken
• Sie Worker-Subagenten für Code-Änderungen spawnen
• Sie Pull Requests durch CI babysitten
• Sie Ergebnisse an den Operator zurückmelden

Sicherheitsleitplanken

Diese Regeln sind NICHT VERHANDELBAR. Kein Agent, Orchestrator oder Plattform-Override darf sie lockern.

Verboten (niemals ausführen)

Befehl / Operation	Grund
gh pr merge	Agenten mergen niemals PRs. Ein Mensch muss mergen.
gh pr merge --auto	Gleiches Verbot; Auto-Merge ist ein Merge.
git push --force (nackt)	Destruktiv; verlustbehaftet. Verwenden Sie nur --force-with-lease.
git push -f (nackt)	Kurzform des gleichen destruktiven Pushs.
GraphQL mergePullRequest	Merge über API ist immer noch ein Merge.
REST PUT /repos/.../merge	Merge über REST ist immer noch ein Merge.
Jegliches Erstellen von Merge-Commits	git merge im Worktree, um PR-Branches zu kombinieren.

Erlaubt für force-with-lease

git push --force-with-lease ist nur erlaubt, wenn:

1. Der Agent seinen eigenen Feature-Branch auf eine aktualisierte Basis rebased.
2. Der Agent einen Force-Push repariert, der aufgrund einer veralteten Remote-Referenz fehlgeschlagen ist.
3. Der Operator explizit einen Force-Push anweist.

Bevor --force-with-lease verwendet wird, MUSS der Agent:

• Überprüfen, dass der aktuelle Branch der zugewiesene Worktree-Branch ist (nicht main, master oder der Branch eines anderen Agents).
• Bestätigen, dass die Remote-Referenz der Erwartung des Agents entspricht (keine unerwarteten Pushs von anderen).

Fix-Cap-Semantik

Regel: Jeder PR erhält maximal 3 Code-Fix-Commits pro Babysit-Zyklus.

• Was zählt: Commits, die Quellcode, Tests, Konfiguration oder Dokumentation ändern, die das Verhalten beeinflussen.
• Was nicht zählt: Merge-Commits durch Rebasing, CI-getriggerte Commits (z. B. Lock-Datei-Updates), Antwort-Kommentare auf dem PR.
• Wenn das Limit erreicht ist: Der Agent MUSS mit dem Committen aufhören und verbleibende Probleme als PR-Kommentare melden. Der Agent antwortet weiterhin auf Review-Kommentare und überwacht CI, pusht aber keine neuen Code-Änderungen.
• Restproblem-Meldung: Wenn das Limit erreicht ist, postet der Agent einen Kommentar mit den verbleibenden CI-Fehlern, ungelösten Review-Threads und empfohlenen nächsten Schritten für einen Menschen oder den nächsten Zyklus.
• Zurücksetzen: Das Limit wird zurückgesetzt, wenn der Operator einen neuen Babysit-Zyklus startet (expliziter Neustart, nicht automatisch).

Branch-/Worktree-Checkliste vor Bearbeitung

Vor jeder Code-Änderung MUSS der Agent überprüfen:

1. Worktree-Isolation: pwd zeigt innerhalb des zugewiesenen Worktree-Pfads ({worktree_root}/{owner}/{repo}/{job_id}).
2. Branch-Korrektheit: git branch --show-current entspricht dem zugewiesenen Feature-Branch.
3. Sauberer Zustand: git status zeigt keine uncommitteten Änderungen aus anderer Arbeit.
4. Remote-Abgleich: git fetch && git status bestätigt, dass der Branch die erwartete Remote verfolgt.
5. Keine grenzüberschreitenden Bearbeitungen: Keine Datei außerhalb des Worktrees wird geändert (keine ../-Pfade, keine absoluten Pfade außerhalb des Worktree-Roots).

Wenn eine Prüfung fehlschlägt, MUSS der Agent abbrechen und die Abweichung melden.

Abschlussbericht

Wenn ein Babysit-Zyklus endet (erfolgreich oder am Limit), meldet der Agent:

• PR-Status: Offen / Bereit für Review / Blockiert
• Fix-Anzahl: Anzahl der Code-Fix-Commits, die in diesem Zyklus gepusht wurden (z. B. „2/3“)
• Restprobleme: Liste der ungelösten CI-Fehler, Review-Kommentare oder Blocker
• Agenten-Attribution: Jeder PR-Kommentar und jede Commit-Nachricht enthält eine Agentenidentifikation

Der Agent DARF NICHT behaupten, er habe den PR gemergt. Wenn der PR als gemergt erscheint, meldet der Agent „PR wurde von einem Menschen gemergt“ und stoppt.

Plattformneutraler Worker-Prompt-Template

Wenn Sie einen Worker-Subagenten spawnen, fügen Sie diese Sicherheitsanweisungen in den Prompt ein:

SICHERHEITSREGELN (nicht verhandelbar):
- NIEMALS einen PR mergen oder eine Merge-API/CLI aufrufen
- NIEMALS nacktes `git push --force` oder `git push -f` verwenden
- `git push --force-with-lease` ist nur zum Rebasing des eigenen Branches erlaubt
- NIEMALS Dateien außerhalb des zugewiesenen Worktrees bearbeiten
- NIEMALS mehr als 3 Code-Fix-Commits pro Babysit-Zyklus committen
- Vor dem Bearbeiten überprüfen: Worktree-Pfad, Branch-Name, sauberer Zustand
- Nach dem Pushen mit SHA und Agenten-Attribution antworten
- Wenn das Limit erreicht ist, Restprobleme melden; keinen weiteren Code pushen

Durchsetzungsebenen

Diese Leitplanken werden auf mehreren Ebenen durchgesetzt:

1. Agent-Skill (diese Datei): Tragbare Dokumentation und Prompt-Vorlagen. Keine Sicherheitsgrenze – Agenten können sie umgehen, wenn sie nicht durch die Plattform eingeschränkt werden.
2. Python-Orchestrator: Richtliniendurchsetzung über die Subprozess-Brücke. Zählt Fix-Commits, validiert Pfade und blockiert verbotene Befehle, bevor sie Rust erreichen.
3. Rust-Kern (wh-core): Harte Durchsetzung. Lehnt unsichere Git/GitHub-Operationen an der Prozessgrenze ab. Dies ist die maßgebliche Sicherheitsebene.

Verteidigung in der Tiefe: Alle drei Ebenen setzen dieselben Regeln durch. Ein Fehler in einer Ebene wird von einer anderen abgefangen.