ptmrio/harness-subagent

Verwendung des Subagenten

Starte einen anderen Coding-Agenten als einmaligen Subagenten und synthetisiere dann die Ergebnisse.

Kernprinzip: Der Agent ist ein Subagent, kein Orakel. Ein Modell, das seine eigene Arbeit überprüft, reproduziert seine eigenen blinden Flecken. Dieser Wert wird zerstört, wenn du die Antwort ohne Bewertung weitergibst.

Orchestrator-Stimme: CTO-Ebene – kurz, präzise, Aufzählungen, ASCII-Vorschauen, wenn sie besser sind als Prosa. Bleib auf Kurs mit dem menschlichen Operator (Annahmen offenlegen; bei irreversiblen Aktionen und ungeklärten Produktpräferenzen nachfragen; keinen stillen Scope erfinden).

Sticky Route: Wenn der Kindprozess auf Nutzungs-/Ratenlimits (oder einen anderen weichen Fehler, der einen Wechsel nahelegt) stößt, nicht auf ein anderes Backend oder Modell umstellen. Den Fehler melden, als UNVERIFIED / blockiert markieren, einmal nachfragen. Ausnahme: Eine no-verdict-Frage derselben Familie / „welcher Harness“ ist ein Nesting Leak – die Identitätsgrenze neu schreiben, einmal neu starten, gleiches Backend; nicht fragen und nicht wechseln. In einer vollständigen Orchestrierungsschleife die Checkliste anhalten – nicht zu späteren Stufen fortfahren, ohne das Ergebnis der fehlgeschlagenen Stufe (z. B. kein Implement, wenn Practices aufgrund eines Limits gescheitert ist).

Wähle keinen Harness aufgrund eines Aufgabenstereotyps, es sei denn, die Benutzerkonfiguration hat diesen Schlüssel (siehe references/user-config.md). Routing-Reihenfolge: diese Äußerung → Benutzerkonfiguration → einmal nachfragen. Gleiches Protokoll für jedes Backend. Rollenpersönlichkeit und Superkräfte: references/roles.md (maßgeblich).

Standardmäßig Review (keine Anwendungsdateien bearbeiten). Anwendungsschreibvorgänge nur erlauben, wenn der Benutzer (oder ein genehmigter Plan) Implement anfordert. Review und Visual dürfen temporäre Dateien erstellen und Berichte schreiben.

Befehlsebenen (nicht mischen)

Dieses Skill ist One-Shot. Der Kindprozess darf es nicht erneut betreten. Vendor-CLIs können verschachteltes Agent/spawn_agent erlauben; das ist keine Lizenz, dieses Protokoll erneut auszuführen.

Ebene	Wer	Befehle	Verboten als „deine“
L0	Mensch	/harness-subagent, „orchestriere“, benannter Harness, self pinnen	spawn.sh-Flags
L1	Eltern, der dieses Skill geladen hat	scripts/spawn.sh --backend --mode, Konfigurations-Routing, gleiche-Familie überspringen, einmal nachfragen, synthetisieren	spawn.sh-Aufrufe in die Kurzbeschreibung setzen; den Kindprozess nach dem Harness fragen
L2	CLI spawn.sh gestartet	Nur Rollen-Superkräfte, Playwright / benannte Screenshots, report.md	Dieses Skill, spawn.sh, requesting-code-review, „welcher Harness?“, Frage derselben Familie

L1 ruft scripts/spawn.sh --mode … auf. Dieses argv ist keine Kindanweisung. Wenn du L2 bist (HARNESS_SUBAGENT_RUN gesetzt, oder die Eingabeaufforderung beginnt mit DU BIST DER ARBEITER), höre auf, dieses Spawn-Protokoll zu lesen und erledige den Auftrag aus der Kurzbeschreibung.

spawn.sh exportiert HARNESS_SUBAGENT_RUN und setzt CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1. Ein verschachtelter spawn.sh stirbt (Variable bereits gesetzt).

Orchestrieren vs. One-Shot

Reihenfolge (in dieser Reihenfolge auswerten):

1. Einzelaufgaben-Einschränkung gewinnt vor One-Shot – die Äußerung nennt einen Auftrag (zweite Meinung, Review dieses Diffs, nur implementieren …, README neu schreiben, X recherchieren) → eine Kurzbeschreibung, ein Spawn. Ein führendes „Orchestriere dies –“ erzwingt nicht die vollständige Schleife.
2. Explizite vollständige Schleife gewinnt – Benutzer sagt „führe die gesamte Schleife aus“ / nennt practices+implement+review zusammen / offen „orchestriere diese Funktion von Anfang bis Ende“ mit keinem Einzelaufgaben-Substantiv → vollständige Checkliste unten. Ein benannter Harness hier pinnt nur das Backend für jede Stufe (oder stufenweise Konfiguration); er kollabiert die Schleife nicht zu einem One-Shot.
3. Andernfalls einmal nachfragen, was sie wollen (vollständige Schleife vs. ein Auftrag).

Checkliste für vollständige Schleife (bereits erledigte oder vom Benutzer aufgehobene Schritte überspringen; ein Auftrag pro Spawn):

1. Practices – Recherche (oder Eltern-self, falls gepinnt): genau zwei Anker – eine offizielle Anleitung von Anthropic + eine von OpenAI. Optional ergänzen (nicht ersetzen) mit Cursor/xAI, wenn der Stack/Harness sie relevant macht. Zitieren + Datumsstempel.
2. Implement – begrenzter Ausschnitt gegen diese Practices. Die vollständige TDD-Tabelle aus roles.md einfügen.
3. Validate – code-review (kontrovers). code-review-visual hinzufügen, wenn UI im Spiel ist.
4. Final Coherence – Elternstandard self (oder ein kurzer Review-Spawn): Logik, Redundanz, allgemeine Plausibilität gegenüber den beiden Ankern und der ursprünglichen Anfrage.

Wenn eine Stufe blockiert ist (einschließlich Sticky-Route-Limits), stoppen und nachfragen – nicht vorwärtsspringen.

Ein Backend auswählen

Nie das eigene Backend des Elternteils spawnen, es sei denn, der Benutzer hat es in dieser Runde genannt (Grok-Elternteil → kein grok; Claude Code-Elternteil → kein claude; Codex-Elternteil → kein codex; Antigravity-Elternteil → kein agy). Ein Harness pro Frage, es sei denn, der Benutzer hat mehrere Meinungen angefordert.

Die Familie ist das übergeordnete Produkt/CLI, nicht die Modell-ID. Cursor Agent, cursor-agent und Grok Bot sind cursor (auch wenn das Modell Grok ist). Grok Build CLI ist grok. Claude Code ist claude. Codex CLI ist codex. Antigravity CLI ist agy. Legacy Gemini CLI ist gemini (eine andere Familie; nicht als agy behandeln). Ein Cursor-Elternteil mit defaults.implement = "cursor" überspringt und fragt einmal nach – dieses Token ist ein Backend, nicht self. self pinnen, wenn diese Sitzung die Arbeit erledigen soll.

Benutzer sagt	Binär (PATH)	Standardmodell (neueste Serie)	Standard-Denken	Flags
Claude, Opus, Fable, ask-claude	claude	opus (auch fable, sonnet, haiku)	xhigh	references/backend-claude.md
GPT, Codex, Sol, Terra, Luna, ask-gpt	codex	gpt-5.6-sol	xhigh	references/backend-codex.md
Grok, ask-grok	grok	grok-4.6	xhigh	references/backend-grok.md
Gemini, Antigravity, agy, ask-gemini	agy	Herstellerstandard (kein --model; Liste: agy models)	high	references/backend-agy.md
Nicht angegeben	Passender defaults.*-Schlüssel in der Benutzerkonfiguration (spec, spec-ui, plan, plan-ui, implement, implement-ui, writer, research, code-review, code-review-visual, …) falls gesetzt und (Backend nicht die Familie des Elternteils, oder Wert ist self-class); sonst einmal nachfragen. Review-Aliase: code-review-task / code-review-adversarial / code-review-adverserial / review → code-review (siehe Auflösungsreihenfolge in user-config).	Konfig [models] / [effort], sonst Tabellenstandards	—	references/user-config.md

Wenn der Benutzer eine Modell-ID pinnt, diese verwenden. Cursor Agent / OpenCode / Droid / legacy Gemini CLI: references/more-clis.md (nicht in scripts/spawn.sh). Konfig-Token gemini ist dieses Legacy-CLI, kein Alias für agy.

Auflisten, was dieser Rechner tatsächlich hat:

claude --help
codex debug models --bundled
grok models
agy models
cursor-agent --list-models

Windows PowerShell: Get-Command claude,codex,grok,agy. Nicht ~/.local/bin/… hartcodiert. agent im PATH ist oft Grok Build, nicht Cursor. Das CLI von Cursor ist cursor-agent.

Es gibt kein harness-spawn-Skill. Veraltete ask-claude / ask-gpt / ask-grok-Stubs: dieses Skill.

Benutzerkonfiguration

Optional. Überlebt Skill-Updates. Nie Präferenzen im Skill-Klon speichern (npx skills add verteilt sich in jedes Agentenverzeichnis).

• Wenn $HARNESS_SUBAGENT_CONFIG gesetzt ist: diese Datei. Fehlende Datei → einmal nachfragen (nicht durchreichen).
• Sonst: ${XDG_CONFIG_HOME:-$HOME/.config}/harness-subagent/config.toml

Schema, Suche und „immer X verwenden“-Schreibpfad: references/user-config.md. Die Datei nicht erstellen, es sei denn, der Benutzer hat darum gebeten, sie zu pinnen.

Wenn der übereinstimmende defaults.*-Wert self, orchestrator, parent oder you ist, die Arbeit in dieser Sitzung erledigen. Keine Kurzbeschreibung schreiben. scripts/spawn.sh nicht aufrufen. Ein Backend der gleichen Familie (grok während du Grok bist) ist nicht self – überspringen und einmal nachfragen, es sei denn, diese Äußerung nennt diesen Harness.

Betriebssystem, Temp, Stdin

Eltern-Agenten leiten oft stdin weiter. Das als feindlich behandeln.

	Linux / macOS / WSL	Windows cmd	Windows PowerShell
Ausführungsverzeichnis	${TMPDIR:-/tmp}/harness-subagent/<run-id>	%TEMP%\harness-subagent\<id>	Join-Path $env:TEMP "harness-subagent\<id>"
Spawn	bash <skill>/scripts/spawn.sh …	Git Bash auf dem Skriptpfad	Git Bash Datei argv (unten) – niemals ein doppelt-anführendes -lc-Rezept

scripts/spawn.sh aus dem Skill-Verzeichnis des SKILL.md, das du in dieser Runde geladen hast (Pfad in der Skill-Headerzeile) aufrufen. npx skills add -g verteilt Kopien; nicht ~/.claude/skills, ~/.cursor/skills und ~/.agents/skills in einer Sitzung mischen.

cwd / -C / --cwd muss ein Pfad sein, den dieses CLI versteht (WSL /mnt/d/… vs. Windows D:\…). Windows claude.exe nicht mit WSL mischen.

Visuelle Screenshots: Claude und Cursor Agent benötigen --add-dir "$RUN" mit Screenshots in $RUN. agy Review/Visual ebenfalls; agy Implement darf nicht --add-dir übergeben (es macht $RUN zu einem beschreibbaren Workspace). Grok: Screenshots in --project (Anwendungsbaum) kopieren, niemals nur in $RUN – Grok kann das temporäre Ausführungsverzeichnis nicht lesen. Codex: -i (Skript --image).

Windows PowerShell (Fallstricke – nicht überspringen)

PowerShell erweitert $(…), cat und $RUN bevor bash sie sieht. Ein doppelt angeführtes & bash -lc "claude … $(cat $RUN/brief.md) > $RUN/last.md" sucht nach D:\c\Users\…, schreibt last.md nach / oder übergibt eine leere/abgeflachte Eingabeaufforderung. system32\bash.exe ist WSL – es kann %TEMP% nicht als /c/… sehen.

1. Git Bash pinnen: "$env:ProgramFiles\Git\bin\bash.exe" (mit Test-Path bestätigen; nicht WSL bash verwenden).
2. brief.md mit dem Write-Tool (UTF-8) schreiben. Nicht Out-File / > von PowerShell 5.1 verwenden (UTF-16LE + NULs).
3. Das Skill-Skript als Argumente ausführen, den Shell-Aufruf im Hintergrund (block_until_ms: 0 in Cursor):

& "$env:ProgramFiles\Git\bin\bash.exe" -- "<skill-dir>\scripts\spawn.sh" --backend claude --mode review --project "D:/Code/app" --run "C:/Users/<you>/AppData/Local/Temp/harness-subagent/<id>"

4. Das Ausführungsverzeichnis mit Shell auflisten (Get-ChildItem / ls). Cursor Glob ist workspace-begrenzt und wird %TEMP% übersehen.
5. Zwei fehlgeschlagene Starts → stoppen. Aus den Eltern-Beweisen antworten. Den Harness als UNVERIFIED markieren. Kein drittes Zitier-Rezept erfinden.

Wenn dieser Elternteil nur einige CLIs automatisch zulässt, wird der Spawn auf bash / bash.exe, dieses Skript oder das Ziel-Backend (codex, …) blockieren. Den Benutzer bitten, diese zuzulassen, oder einen Genehmigungsmodus verwenden, der den einen Spawn genehmigen kann. Keine maschinenbezogene Zulassungsliste hartcodieren.

Spawn pinnt Auto-äquivalente Berechtigung: Claude/Grok --permission-mode auto. Codex alle Modi --approve-for-me (nicht zusätzlich --sandbox übergeben: 0.147 Mutex). agy Implement --dangerously-skip-permissions (agy hat keinen Klassifizierer Auto; das ist YOLO). agy Review lässt es weg. Claude Review lässt Edit/Write in --tools weiterhin weg (Bash bleibt für temporäre Dateien). Nicht --ask-for-approval an codex exec übergeben (nur TUI; exec lehnt es ab). Die Einschränkung für Anwendungsbearbeitung ist die Kurzbeschreibung („Bearbeite keine Anwendungsdateien.“), nicht eine schreibgeschützte Sandbox.

Gemeinsames Protokoll

0. Tor. Nenne die eine Sache, die du aus diesem Repo/diesem Kontext nicht beantworten kannst. Wenn du sie nicht nennen kannst, nicht spawnen – es sei denn, diese Äußerung hat bereits einen Harness genannt (Äußerung gewinnt immer noch; writer=self unterdrückt nicht „Bitte Claude, die README neu zu schreiben“). Benennung, Stil, Formatierung und „bereits versucht“, die bereits die Antwort sind, sind keinen Lauf wert. Anhaltende Writer/Research (eine README-Neuschreibung, eine Wettbewerbsrecherche) ist keine „Benennung“: Spawnen, wenn die aufgelöste Route ein CLI ist.
1. brief.md unter dem temporären Ausführungsverzeichnis schreiben (niemals innerhalb des Repos).
2. scripts/spawn.sh im Hintergrund spawnen (Minuten; ein Vordergrund-Timeout vernichtet Ausgaben). Das Skript nicht kopieren oder bearbeiten.
3. Warten, bis der Prozess beendet ist. Dann $RUN/last.md und $RUN/capture-status.txt lesen. Prozess noch aktiv + noch kein VERDICT → nicht fertig. spawn.sh bevorzugt bereits $RUN/report.md gegenüber der finalen Standardausgabe und normalisiert fettgedruckte/VERDICT:-Zeilen. Wenn der Status usage-limit oder no-verdict ist, den Harness als UNVERIFIED / blockiert markieren – kein Urteil erfinden und nicht auf andere Backends umstellen (Sticky Route). Ausnahme: no-verdict, das eine Frage derselben Familie / „welcher Harness“ ist, ist ein Nesting Leak – die Identitätsgrenze neu schreiben und einmal neu starten (gleiches Backend). Keinen bereits abgeschlossenen Auftrag aufgrund einer Präambel neu starten.
4. Synthetisieren – niemals nur einfügen.

Die Kurzbeschreibung schreiben

Aufgabenbeschreibung, kein Daten-Dump. Diffs oder Dateiinhalte nicht einfügen – Pfade und eine begrenzte Untersuchung nennen. Ausnahme: Dateien, die aus dem Arbeitsverzeichnis nicht erreichbar sind (Screenshots unter dem temporären Ausführungsverzeichnis).

• Benannte Dateien/Symbole gegenüber „das Repo erkunden“ bevorzugen.
• Diff: exakter Bereich, git diff <A>..<B> -- <pfade…>.
• Visual/Bestätigen: git log, vollständiger Baum-git diff, Status-Dumps verbieten. spawn.sh --image ist nur für Codex. Claude: Screenshots in $RUN kopieren (erhält bereits --add-dir "$RUN"). Grok: Screenshots in --project kopieren. Die Dateien in der Kurzbeschreibung nennen.
• Eltern-Beweise unter Was wurde bereits versucht setzen. „Überprüfe dies“ gegenüber „Entdecke neu“ bevorzugen. Wenn du bereits gh/curl ausgeführt hast und Codex Review möglicherweise kein Netzwerk hat, die Ausgabe hier einfügen und die erneute Ausführung dieser Befehle verbieten.
• Produkt-Override: Wenn der Benutzer eine Produktentscheidung festgelegt hat, dies sagen.

Sechs Teile, in dieser Reihenfolge:

1. Kind-Identitätsgrenze – zuerst, wörtlich, aus references/roles.md einfügen. Niemals scripts/spawn.sh oder --mode visual in der Kurzbeschreibung schreiben (L2 behandelt das als Befehl zum erneuten Orchestrieren).
2. Ziel – ein Satz, der das Urteil/Ergebnis nennt (Rollenkarten-Zielhinweis).
3. Wo suchen – Pfade, begrenzte Befehle, Symbole; Bearbeitungs-Zulassungsliste, wenn Implement.
4. Was wurde bereits versucht
5. Was würde meine Meinung ändern – entscheidende Beweise (Review) oder Abnahmetore (Implement).
6. Rückgabeformat – aus references/roles.md einfügen: den Rückgabevertrag der Rolle (enthält report.md vor der Bereinigung schreiben), Superkräfte-Karte (exakte Namen), Muss/Darf-nicht, und für implement/implement-ui die vollständige TDD-Richtlinientabelle (niemals „siehe roles.md“ allein). Rollenkarte gewinnt über jede ältere Stub-Formulierung. Den Pfad des Ausführungsverzeichnisses für report.md nennen (aus dem --run-Argument).

…

[übersetzt, gekürzt]