doftasted/AgentDock

trellis-channel

trellis channel ist die lokale Multi-Agenten-Kollaborationslaufzeit. Greife darauf zu, wenn Agenten über ein dauerhaftes Ereignisprotokoll kommunizieren müssen, wenn ein Arbeiter als Peer-Prozess gespawnt werden soll, wenn ein laufender Arbeiter unterbrochen / debuggt werden muss, oder wenn Feedback auf einem dauerhaften --type forum-Kanal aufgezeichnet werden soll.

Typische Benutzersignale: "mit codex/claude diskutieren", "mit einem anderen Agenten brainstormen", "einen Implementierungs-/Prüf-Worker spawnen", "Agent prüft", "ein Issue-Board / Changelog-Forum eröffnen", "diesen Thread ansehen", "Kanal ist blockiert / keine Ausgabe", "Fortschritt wurde abgeschnitten", "wie schreibe ich diesen Kanal-Befehl".

Diese Skill ist ein Index. Lade nur die Referenzdatei für die aktuelle Aufgabe – lade nicht alle vorab.

Erste Befehle

trellis --version
trellis channel --help
trellis channel list --all
trellis channel list --scope global --all

Wenn der Benutzer einen Kanal oder Thread nennt, überprüfe ihn, bevor du nach Hintergrundinformationen fragst:

trellis channel forum <board> --scope global
trellis channel thread <board> <thread> --scope global
trellis channel context list <board> --scope global --thread <thread>

Nach Benutzerabsicht routen

Benutzerabsicht	Lesen
"mit codex/claude diskutieren", "mit einem anderen Agenten brainstormen"	references/workflows.md
"einen Implementierungs-/Prüf-Agenten schicken", "Agent prüft", "Arbeiter spawnen"	references/workflows.md, dann references/workers.md
"Issue-Bereich / Themen-/Changelog-/Board eröffnen", "ein Forum erstellen"	references/forum.md
"diesen Thread / verknüpften Kontext ansehen", "Thread inspizieren"	references/forum.md
"Kanal blockiert / keine Ausgabe / Fortschritt abgeschnitten", "Arbeiter hängt"	references/progress-debugging.md
"Wie lautet der spezifische Befehl", "welche Flags nimmt X"	references/command-reference.md

Kernregeln

• Neue Forum-Kanäle verwenden --type forum. Ein thread ist ein Element innerhalb eines Forum-Kanals.
• Verwende --context-file / --context-raw und trellis channel context add/delete/list. --linked-context-* ist veraltete Terminologie.
• Verwende --stdin oder --text-file für lange Nachrichten. Platziere keinen langen gemischten chinesisch/englischen Text im positionellen Shell-Argument.
• Die hübsche messages-Ausgabe ist ein Operator-Dashboard und kann den Fortschritt abschneiden. Verwende --raw für die Prüfung.
• --as ist der Sprecher- oder Arbeiter-Handle, abhängig vom Befehl. Verwende explizite, stabile Namen, wenn mehrere Agenten oder Sitzungen beteiligt sind.
• --scope project (Standard) arbeitet im aktuellen Projekt-Bucket des aktuellen Arbeitsverzeichnisses; --scope global arbeitet im gemeinsamen __global__-Bucket. Wähle den Geltungsbereich bewusst – ein globales Board ist in Projektlisten unsichtbar, es sei denn, --scope global wird übergeben.
• Beim Brainstorming führe mehrere Drucktestrunden durch. Eine Antwort plus eine Bestätigung ist eine Überprüfung, kein Brainstorming.
• Dispatcher-Warte-Muster: Verwende --kind done / --kind turn_finished (von trellis emittierte Systemereignisse), NICHT ein benutzerdefiniertes --tag als Abschlusssignal. Die CLI-Hilfe listet phase_done / question als --tag-Beispiele, aber nur interrupt ist ein reservierter Tag mit fest programmiertem trellis-Verhalten; die anderen sind undurchsichtige Benutzerlabels. Sich darauf zu verlassen, dass ein Arbeiter send --tag <my_signal> ausführt, ist unzuverlässig – LLM-Arbeiter schreiben oft die Tag-Zeichenfolge in Prosa, anstatt den eigentlichen CLI-Befehl auszuführen. Siehe references/command-reference.md "tag vs kind".
• Forum-Kanäle sind ereignisgesteuert. Analysiere nicht zuerst events.jsonl; verwende forum, thread, messages --thread und context list.
• @mindfoldhq/trellis-core besitzt den wiederverwendbaren Kanal-/Thread-Zustand, Ereignisanhänge, Sequenzvergabe, Kontext-/Titelprojektionen, Reducer und Aufgabenhelfer. Die CLI besitzt Flags, Terminal-Darstellung, Eingabeaufforderungen, Arbeiter-Lebenszyklus und Prozessbeendigungen.

Referenzdateien

• references/workflows.md – kanonische Kollaborationsmuster A–F (Peer-Brainstorming, gespawnte Überprüfung, Dispatch-and-Wait, Forum-Issue-Erfassung, Unterbrechen-und-Umleiten, One-Shot-Ausführung).
• references/forum.md – Forum-Kanäle, Kontext, Titel, Umbenennung, Changelog-Foren, Thread-Filterung.
• references/workers.md – Spawnen, Agentenkarten, Kontextinjektion (--file / --jsonl), Unterbrechungen, Kill-Semantik.
• references/progress-debugging.md – Fortschritts-/Rohinspektion, Diagnose blockierter Arbeiter, OOM-Schutz, Exit-Codes.
• references/command-reference.md – aktuelle CLI-Befehlsreferenz (jeder Unterbefehl, jedes Flag, Ausgabekonventionen, Bereichs-/Typmodell).

Nicht geeignet für

• Einmalige statische Überprüfungen, bei denen eine Markdown-Datei und eine Eingabeaufforderung ausreichen.
• Ersetzen normaler Tool-Aufrufe durch Selbstprotokollierung.
• Langzeit-Gedächtnisabfrage. Verwende dauerhafte Forum-Kanäle für umsetzbare Probleme, und trellis mem (die trellis-session-insight-Skill) für die Sitzungs-/Verlaufssuche.