Lies den Runtime-Adapter, bevor du diesen Workflow befolgst. Seine Runtime-Mappings gelten für alle referenzierten Playbooks und Skripte.
Was macht pstack-trio?
Drei Agenten, eine Herdr- oder Rex-Sitzung, ein Repository. Der Master besitzt die Urteilsfähigkeit, der Sidekick besitzt den Working Tree, und der Consultant besitzt die zweite Meinung. Jede Nachricht zwischen ihnen ist eine Datei im Trio-Speicher plus eine einzeilige Aufforderung, die die Datei benennt. Das Terminal ist niemals die Aufzeichnung, da Agenten auf dem alternativen Bildschirm kein Scrollback hinterlassen.
Das Trio ist pstack-pair mit einem zusätzlichen Consultant. Die Planrunden, Briefings, Check-ins, Steuerungen und Überprüfungen des Paares bleiben unverändert; der Consultant nimmt an jeder Planrunde teil und beantwortet Konsultationen, wenn ein Befund das Design ändert. Er sendet niemals Nachrichten an den Sidekick und schreibt nie in den gemeinsamen Tree.
Vorbedingungen
- Innerhalb von Herdr (
test "${HERDR_ENV:-}" = 1) oder Rex (REX_BLOCKgesetzt). Außerhalb von beiden, sage dies und stoppe. - Lade die Fähigkeit des Multiplexers für Paneel- und Agentensteuerung: Herdrs
~/.agents/skills/herdr/SKILL.md(oderherdr --skill, wenn diese Datei fehlt), oder Rex'rex skill show. Deren Sicherheitsregeln gelten während des gesamten Prozesses. In Rex lies Laufen in Rex. herdroderrexund Python 3.11 oder höher (python3) im PATH.scripts/pair.sh helplistet jeden Speicher- und Kanalvorgang auf; verwende dies anstelle von handgebautenherdr- oderrex-Aufrufen für das Trio.- Mindestens zwei verschiedene Agentenarten unter Master, Sidekick und Consultant.
pair.sh spawnliest die Art des Masters vom Multiplexer und beendet sich mit Exit-Code 8, wenn alle drei gleich wären; sage dem Menschen, eine andere Art zu wählen oderpstack-pairzu verwenden. Sidekick und Consultant können eine Art teilen. - Starte den Master im Auto-Modus. Devin standardmäßig mit
--permission-mode dangerous, um Berechtigungen zu umgehen. Andere Arten übernehmen den Modus des Masters.pair.sh permissiongibt den erkannten Master-Modus aus.--permission <modus>überschreibt beide erstellten Rollen;--consultant-permission <modus>überschreibt nur den Consultant. Native Berechtigungsflags nach--überschreiben den Standard für jede durch diesen Aufruf erstellte Rolle.--permission autowählt Devin Smart-Modus. Arten ohne Übersetzung verwenden native Flags nach--.spawnüberspringt auch die Ordnervertrauensaufforderung jeder Art, die einen unbeaufsichtigten Agenten in einem noch nicht gesehenen Ordner aufhängen würde: Pi erhält--approve, Devin--respect-workspace-trust false. Ein Vertrauensflag nach--überschreibt dies. Ein erstellter Claude startet auch ohne MCP-Server (--strict-mcp-configund eine leere Konfiguration), da jeder Server ein Prozess pro Sitzung ist; ein--mcp-confignach--behält deine bei. Claude und Codex fragen stattdessen, ob sie einem noch nicht gesehenen Ordner vertrauen sollen; diese Entscheidung liegt beim Menschen, daher lehntspawnden Dialog ab und stoppt mit der Anweisung: Öffne diesen Agenten einmal im Repo und vertraue ihm.
Rollen
| Master | Sidekick | Consultant | |
|---|---|---|---|
| Besitzt | Plan, Briefings, Konsultationen, Überprüfung, Entscheidungen, den Menschen | den Working Tree, Tests, Diagnose, Beweise | Designkritik, zweite Durchsichten, Prototypen |
| Führt pstack aus als | Poteto-Mode-Framing, how, architect, Überprüfungsfähigkeiten | das Playbook, das jedes Briefing benennt, mit seiner Aufgabenliste | how, why, architect-Alternativen, interrogate-Haltung, blast-radius bei Diffs |
| Schreibt | nur den Trio-Speicher | Dateien innerhalb des Geltungsbereichs des Briefings, plus dessen Fortschrittsprotokoll und Berichte | Beratungsdateien und einen Scratch-Worktree, den es entfernt |
| Liest den Tree | immer, schreibgeschützt; führt Überprüfungen im Scratch bei einem Commit durch | immer | immer, schreibgeschützt |
| Spricht durch | Pläne, Briefings, Steuerungen, Konsultationen, Überprüfungen, stehende Anordnungen, Tore | Fortschrittszeilen, Berichte | Beratung |
Betrete deine Rolle. Master: references/master.md. Sidekick: references/sidekick.md. Consultant: references/consultant.md.
Trio-Speicher
${XDG_STATE_HOME:-$HOME/.local/state}/pstack/trio/<slug>/, erstellt von pair.sh init. Ein Schreiber pro Datei.
| Pfad | Schreiber | Inhalt |
|---|---|---|
pair.json | Master via pair.sh | Agentennamen, Paneel-IDs, Arten, Arbeitsverzeichnis, Git-Root, offene Scratch-Liste, Fallback und Failover des Sidekicks, Paneel-Platzierung (Split oder Tab) |
standing-orders.md | Master | nummerierte Einschränkungen, die per Pfad in jedes Briefing eingefügt werden |
plans/NNN-<slug>.md | Master | eine Planrunde, aus der Planvorlage |
briefs/NNN-<slug>.md | Master | eine Einheit, aus der Briefingvorlage |
progress/NNN-<slug>.md | Sidekick via pair.sh progress | eine Zeitstempelzeile pro abgeschlossenem Schritt oder Methodenwechsel |
steers/NNN-<slug>-s<k>.md | Master | Mid-Briefing-Anweisung k für Einheit NNN, aus der Steuervorlage |
consults/NNN-<slug>-c<k>.md | Master | Frage k zu Einheit NNN an den Consultant, aus der Konsultationsvorlage, mit einer kind: von design, finding, objection oder review |
reports/NNN-<slug>-s<k>.md | Sidekick | Einwand gegen Steuerung k, aus der Steuerungsantwortvorlage |
reports/NNN-<slug>.md | Sidekick | Beweise für Briefing NNN, aus der Berichtsvorlage, oder die Zustimmungs-/Einwandsantwort zu Plan NNN, aus der Planantwortvorlage |
advice/NNN-<slug>.md | Consultant | Designkritik zu Plan NNN, aus der Planberatungsvorlage |
advice/NNN-<slug>-c<k>.md | Consultant | Antwort auf Konsultation k, aus der Beratungsvorlage |
scratch/<id> | Consultant oder Master via pair.sh scratch | Link zu einem Wegwerf-Worktree für eine Konsultation (NNN-<slug>-c<k>) oder Überprüfung (NNN-<slug>-review), bei einem Commit oder dem Live-Zustand, außerhalb des Repos unter ${XDG_STATE_HOME:-~/.local/state}/pstack/scratch/ aufbewahrt (PSTACK_SCRATCH_ROOT verschiebt es), dem Claude und Codex einmal pro Host vertrauen müssen (kitchen.py doctor prüft); entfernt, wenn erledigt |
reviews/NNN-<slug>.md | Master | Urteil über Einheit NNN, aus der Überprüfungsvorlage; nennt die Beratung, auf die es sich stützt, und etwaige Überstimmung |
gates.md | Master | offene Fragen an den Menschen |
decisions.tsv | Master via pair.sh log | der "Zeig-mir-deine-Arbeit"-Pfad |
status.md | pair.sh status | abgeleitete Tabelle; niemals manuell bearbeitet |
queue | Master via pair.sh queue und dispatch | der Pfad des nächsten Briefings, ein Slot |
steps/NNN-<slug>.tsv | Sidekick via pair.sh step | eine Zeile pro festgelegtem Schritt: Nummer, Commit, Zeit, Notizen, die es auflöst, Zusammenfassung |
notes/NNN-<slug>-n<k>.md | Master via pair.sh new-note und note | Überprüfung der Schritte der Einheit bis Schritt k, aus der Notizvorlage: blockierende Elemente und Folgeaktionen |
followups.md | Master via pair.sh note | Folgeaktionen aus jeder Notiz, für ein späteres Briefing oder ein Issue |
session-handoff.md | Master | kompakte Wiederherstellungs- und nächste-Aufgabe-Kontext, beim Bootstrap gelesen |
sessions/ | pair.sh spawn / rotate | vorherige Bereitschaftsberichte; aufbewahrte Sitzungsexporte und Zeitbeweise |
events.tsv | jeder pair.sh-Befehl | eine Zeile pro Nachricht, Bericht, Aufwachen und Protokolleintrag, gelesen von pair.sh metrics |
NNN ist eine nullgepolsterte Sequenz, die von Plan oder Briefing, Bericht, Beratung und Überprüfung gemeinsam genutzt wird, sodass die Dateien für eine Einheit zusammen sortiert werden.
Nachrichten
| Aufforderungstext | Richtung | Helfer des Senders | Zug des Empfängers |
|---|---|---|---|
| Bootstrap (nennt die Fähigkeit, die Rolle und den Speicher) | Master an Sidekick und Consultant | pair.sh spawn | Bootstrap-Schritte, reports/000-ready.md oder advice/000-ready.md, antworte READY |
pstack-trio PLAN <plan-path> | Master an Sidekick und Consultant gleichzeitig | pair.sh discuss | Sidekick verankert den Plan im Code; Consultant kritisiert das Design; jeder schreibt Zustimmung oder Einwand, beendet den Zug |
pstack-trio BRIEF <brief-path> | Master an Sidekick | pair.sh dispatch | führe das Briefing aus, schreibe seinen Bericht, führe pair.sh finish aus, beende dann den Zug mit der REPORT-Zeile |
pstack-trio BRIEF <brief-path>, in Warteschlange | Master an einen arbeitenden Sidekick | pair.sh queue | der Master verteilt es nach einer neuen Sitzung; pair.sh next lehnt ab |
pstack-trio STEER <steer-path> | Master an einen arbeitenden Sidekick oder einen, der aufgrund eines Einwands pausiert | pair.sh steer | lies es zwischen Tool-Aufrufen; stimme zu und fahre fort, oder lege Einwand mit Beweisen ein und beende den Zug |
pstack-trio CONSULT <consult-path> | Master an Consultant | pair.sh consult | lies die genannten Dateien, erstelle bei Bedarf einen Prototypen im Scratch, schreibe die Beratung, beende den Zug |
pstack-trio REPORT <report-path> | Sidekick an Master | pair.sh finish (oder notify) | lies den Bericht, überprüfe |
pstack-trio ADVICE <advice-path> | Consultant an Master | pair.sh notify | lies die Beratung, entscheide |
pstack-trio STOP <speicher> | Master an Sidekick und Consultant | pair.sh stop | pausiere sicher, schreibe einen Stoppbericht oder eine Beratung |
discuss kehrt zurück, wenn beide Agenten sich einigen, mit einem Antwortpfad und Status pro Rolle. Ein Sidekick, der an einer Einheit arbeitet, hält keine Runde auf: Der Consultant erhält den Plan sofort, die Hälfte des Sidekicks ist deferred (Exit-Code 4), und das erneute Ausführen von discuss, sobald der Sidekick berichtet, sendet nur diese Hälfte. consult kehrt zurück, wenn der Consultant in idle, done oder blocked übergeht. dispatch und wait kehren zurück, wenn die Antwort des Sidekicks eintrifft, der Bericht seit der Nachricht geschrieben wurde, oder wenn er blocked ist; eine Beruhigung vom Multiplexer allein wird nicht als vertrauenswürdig angesehen: Ein Devin-Sidekick zeigt Leerlauf an, wenn eine Aufforderung eintrifft und zwischen Schritten, und kann in einem schmalen Paneel für einen gesamten Durchlauf als erledigt angezeigt werden. Daher wird eine Beruhigung anhand der "Esc to interrupt"-Zeile des Paneels überprüft, und eine ohne Bericht, die eine Minute anhält, beendet die Wartezeit mit report: missing. dispatch und wait kehren auch zum Check-in-Intervall mit einer Zusammenfassung zurück. wait kehrt auch in dem Moment zurück, in dem der Bericht eines verteilten Briefings eintrifft, selbst wenn der Sidekick bereits das nächste Briefing in der Warteschlange übernommen hat; running: gibt dann das Briefing an, an dem er arbeitet. notify fordert den Master nur auf, wenn der Master im Leerlauf ist. Eine Nachricht, die du nach der Kompaktierung erhältst, nennt immer noch diese Fähigkeit und die zu lesende Datei, also lade die Fähigkeit neu und fahre mit dieser Datei fort.
Zuerst planen
Die Implementierung beginnt nur mit einem Plan, dem der Sidekick zugestimmt hat und zu dem der Consultant beraten hat. Der Master entwirft plans/NNN-<slug>.md mit dem gewählten Design, den abgewogenen Alternativen und deren Vor- und Nachteilen und sendet ihn dann mit pair.sh discuss, was beide Agenten gleichzeitig erreicht. Der Sidekick prüft jeden Schritt gegen den Code und antwortet mit Zustimmung oder Einwand samt Beweisen. Der Consultant kritisiert das Design selbst: Datenform, Grenzen, was die Alternativtabelle übersieht, und antwortet mit Zustimmung oder Einwand. Der Master führt beide in die nächste Runde oder eine Überprüfung mit dem Urteil agreed zusammen.
Der Consultant ist beratend. Ein Einwand des Consultants blockiert agreed nicht; der Master kann ihn mit dem Grund im Abschnitt "Überstimmt" der Überprüfung und einem Entscheidungseintrag überstimmen. Eine Beratungsdatei für die Planrunde muss jedoch vorhanden sein: pair.sh dispatch lehnt ein Feature, einen Bug-Fix, eine Refaktorisierung, ein Leistungsproblem oder ein pstack-tdd-Briefing ab, dessen Plan keine Consultant-Beratung oder keine agreed-Überprüfung hat. Schreibgeschützte und forensische Briefings benötigen keinen Plan; das Diagnose-Briefing eines Fehlers läuft vor seinem Plan. Drei Runden ohne Einigung werden zu einem Tor für den Menschen, mit allen Positionen in gates.md.
Konsultationen
Eine Konsultation ist die Frage des Masters an den Consultant außerhalb einer Planrunde. pair.sh new-consult <speicher> <NNN> --kind <art> erstellt die Datei für Einheit NNN; pair.sh consult sendet sie und wartet auf die Beratung.
| Art | Wann | Der Consultant antwortet |
|---|---|---|
| design | der Master wägt eine Richtung vor einem Plan oder einer Steuerung ab | welcher Weg und warum, mit den Abwägungen |
| finding | eine Check-in-Zusammenfassung, ein Bericht oder ein Diff hat etwas Unerwartetes zutage gefördert | ob es das ist, wonach es aussieht, und was es ändert |
| objection | der Sidekick hat Einwand gegen eine Steuerung erhoben | wer auf Basis der Beweise recht hat und die Alternative |
| review | ein Urteil ist angefochten oder eine Einheit ist bei ihrer zweiten Überarbeitung | annehmen, überarbeiten oder ablehnen, mit Erkenntnissen |
| glance | ein Check-in zeigt den ersten Commit oder einen großen Diff bei einer Einheit, deren Überarbeitung am teuersten wäre | in fünf Minuten: würde die Überprüfung "Überarbeiten" sagen und warum, oder none |
Konsultationen sind obligatorisch vor: einer Steuerung, die vom vereinbarten Design abweicht, einer ersetzenden Steuerung nach einem Sidekick-Einwand und einem revise-Urteil beim zweiten Versuch einer Einheit. Sie sind optional an anderer Stelle, und es wird keine für die Landeeinheit gesendet: Jede Diskussion und Überprüfung endet vor der Landung. Drei Konsultationen pro Einheit; new-consult lehnt eine vierte ohne --force ab, denn eine vierte bedeutet, dass das Design falsch ist und in eine Planrunde gehört. Ein Glance liegt außerhalb dieser Obergrenze, eine pro Einheit, und ist niemals obligatorisch: Das Kontingent des Consultants ist das knappe, also gib es dort aus, wo eine späte Überarbeitung am teuersten wäre.
Jede Konsultation läuft jederzeit, ob der Sidekick arbeitet oder nicht. consult stempelt den Zustand des Sidekicks und HEAD auf die Datei; der Consultant liest festgelegte Arbeit bei diesem HEAD und alles Unfestgelegte nur durch eine pair.sh scratch-Momentaufnahme, niemals einen Tree, der sich darunter bewegt. Jede Konsultation hat ein Zeitlimit, standardmäßig fünfzehn Minuten und fünf für einen Glance; danach schreibt der Consultant eine partial-Beratung und beendet den Zug.
Check-ins und Steuerungen
Unverändert von pstack-pair: Der Sidekick hängt Fortschrittszeilen an, dispatch und wait geben eine Check-in-Zusammenfassung im Intervall zurück, und eine Steuerung ist die einzige Nachricht, die einen arbeitenden Sidekick erreichen darf. Zwei frische Steuerungen pro Briefing, zwei Runden pro Steuerung. Der Consultant fügt einen Schritt hinzu: Wenn eine Zusammenfassung oder ein Einwand einen Befund zeigt, der das Design ändert, konsultiert der Master vor der Steuerung, und die Ausrichtung der Steuerung zitiert den Beratungspfad.
Aufgabensitzungen jeder Art
Ein Sidekick jeder Art (Claude, Codex, Devin, Pi, Prime, Muse) verwendet eine frische Konversation für jedes verteilte Briefing: keine Verlaufsanreicherung über Einheiten hinweg. pair.sh dispatch erzeugt die Konversation mit dem initialen Prompt des Briefings und bindet sie an den Sidekick; der Sidekick hält einen einzigen Zug, der alle Schritte des Briefings enthält. Der Sidekick ist zu diesem Zeitpunkt der einzige Unterhaltungspartner; der Master spricht ausschließlich über Steuerungen, die nur lesend gelesen werden, und der Consultant spricht überhaupt nicht. Dies stellt sicher, dass kein Tool-Aufruf eines Agenten den Baum eines anderen stört.
Eine Sitzung endet mit einem Bericht oder einem STOPP. Der Master bereitet die nächste Sitzung vor, indem er die Aufgabenliste des Briefings zurücksetzt: pair.sh dispatch entfernt die vorherige Aufgabenliste und schreibt eine neue aus dem Briefing, falls vorhanden. Der Sidekick beginnt mit einer leeren Aufgabenliste, es sei denn, sie wird bereitgestellt; wenn keine bereitgestellt wird, generiert der Sidekick seine eigene aus dem Briefing.
Das Kontingent des Masters: Eine Frage pro Check-in, eine Überprüfung pro Bericht, eine Konsultation pro Befund, eine Steuerung pro Einwand. Der Master sendet niemals drei Nachrichten ohne Pause: Der Sidekick braucht Zeit zum Arbeiten.
Landung
Einheiten landen, wenn der Master eine agreed-Überprüfung ausstellt und das Briefing schließt. Eine Überprüfung ist eine Datei; der Master schreibt sie, der Sidekick liest sie. Der Master sendet das Briefing nicht explizit, bis die Überprüfung abgeschlossen ist; der Sidekick wartet auf das nächste Briefing. Der Consultant wird über die Landung informiert, falls vorhanden.
Der Sidekick kann seine Arbeit einreichen: pair.sh finish schreibt den Bericht und signalisiert, dass der Sidekick bereit für das nächste Briefing ist. Der Master kann dann die Überprüfung schreiben oder eine weitere Steuerung senden. Der Sidekick kann nicht von sich aus landen.
Wenn der Sidekick einen Bericht ohne Einwände einreicht, schreibt der Master die Überprüfung mit agreed. Wenn der Sidekick Einwände hat, schreibt der Master die Überprüfung entweder mit agreed und überstimmt den Einwand oder schickt eine weitere Steuerung. Wenn der Consultant Einwände hat, schreibt der Master die Überprüfung entweder mit agreed und überstimmt den Einwand oder schickt eine weitere Konsultation.
Das Landen entfernt die Aufgabenliste des Briefings und verschiebt seinen Bericht in das Sitzungsarchiv. Das Briefing selbst bleibt im Briefingsspeicher und wird als abgeschlossen markiert.
Ausnahmen
pstack-pair hat zwei: die Drei-Runden-Klippe und die Landungsverweigerung des Masters. Hier kommen drei hinzu:
| # | Ausnahme | Wer löst aus | Auswirkung |
|---|---|---|---|
| 1 | Drei Konsultationen pro Einheit erreicht und der vierte Befund | pair.sh new-consult | lehnt ab, es sei denn --force; der Master muss eine neue Planrunde eröffnen |
| 2 | Consultant antwortet auf eine Planberatung mit Einwand | pair.sh discuss | sagt dem Master, dass der Plan geändert werden muss, bevor der Sidekick zustimmen kann; discuss gibt blocked zurück |
| 3 | Sidekick ist beschäftigt, aber Consultant erhält Plan | pair.sh discuss | verteilt den Plan sofort an den Consultant; die Hälfte des Sidekicks ist deferred |
Metriken
pair.sh metrics liest events.tsv und meldet: Dauer pro Einheit, Anzahl der Konsultationen, Anzahl der Steuerungen, Anzahl der Überprüfungen, Sidekick-Auslastung. Keine externen Abhängigkeiten.