Was macht baton?
Verwende die gebündelte Python-Engine als autoritatives lokales Aufgaben-Ledger. Führe Befehle explizit aus; dieser Skill startet keinen Daemon, erkennt keine Modellnutzungslimits und kontaktiert keine anderen Agenten automatisch.
Chat-Aktionen interpretieren
Benutzer rufen diesen Skill normalerweise im Chat auf, z. B. /baton handover TASK-01 to pc1-codex, $baton continue TASK-01 oder /baton:baton status, je nach Host. Interpretiere die restlichen Wörter als Aktionsanfrage und führe den entsprechenden Engine-Befehl für den Benutzer aus. Dies sind Anfragen an diesen einen Skill, keine separaten registrierten Befehle oder Terminalbefehle.
| Angeforderte Aktion | Engine-Aktion |
|---|---|
init | Bootstrap falls nötig; Projekt inspizieren; InitFresh nur für ein neues Board. |
join | JoinExisting. |
status, tasks, packet TASK | Status, Tasks, WebPacket. |
add TASK "Titel" with files ... | AddTask, mit Abhängigkeiten falls angegeben. |
start TASK, claim TASK | SilentHandshake; --git-branch für Git-Arbeit und einen isolierten Worktree verwenden, wenn angefordert. Dann nur implementieren, wenn der Benutzer nach der Implementierung gefragt hat. |
checkpoint TASK with message ... | Checkpoint; --push nur innerhalb der Upload-Autorisierung des Benutzers hinzufügen. |
progress TASK to 60 percent | UpdateProgress, mit einer wahrheitsgemäßen Fortschrittsangabe und Notizen. |
handover TASK to AGENT, handoff TASK to AGENT | AtomicHandoff; den aktuellen Prompt, Änderungen und verbleibende Arbeit aus dem Gespräch einschließen. |
continue TASK, resume TASK | CheckOrContinue; vor dem Bearbeiten auf die Besitzentscheidung reagieren. |
done TASK | Relevante Projektprüfungen ausführen, dann Done, wenn die Implementierung fertig ist. |
review TASK | Die gepinnten Änderungen und relevanten Prüfungen als ein anderer Agent inspizieren, dann SubmitReview. |
reopen TASK, merge TASK, release TAG, revert TASK, recover TAG | Entsprechend ReopenTask, MergeTask, ReleaseTag, RevertTask, RecoverTag. |
release files ... from TASK | ReleaseFiles für die angegebenen Claims. |
resolve recovery | ResolveRecovery; unerledigte Arbeiten und deren Journal behalten, falls abgelehnt. |
abandon recovery | ResolveRecovery --abandon-recovery nur, wenn die Aufgabe explizit gefordert wird. Verbleibende Reparaturen melden. |
selftest | SelfTest. |
reset workspace | ResetWorkspace --confirm-reset nur für eine explizite autorisierte Zurücksetzung durch den Lead. |
Löse Aufgaben-IDs und Pfade aus der Anfrage und dem aktuellen Board auf. Frage nach fehlenden Informationen, wie einem neuen Projektschlüssel oder einer mehrdeutigen Kollaborateur-Identität. Übergib die Kollaborateur-ID dieses Gesprächs explizit an identitätsbezogene Engine-Aktionen; ein anderer Agent kann die gespeicherte ID der gemeinsamen lokalen Sitzung geändert haben. Respektiere frühere Autorisierungen im Gespräch. MergeTask und ReleaseTag versuchen Remote-Uploads; verwende sie daher nicht gegen ein konfiguriertes Remote, wenn die Benutzeranfrage Uploads verbietet.
Ein Projekt einrichten
Voraussetzungen: Python 3.10+ und Git. Wähle einen verfügbaren Python 3-Interpreter aus (python3, python oder py -3 unter Windows); nimm nicht an, dass der Windows-python3-Alias funktioniert.
Führe vor dem ersten Engine-Befehl in einem Projekt das eigene scripts/bootstrap.py dieses Skills mit dem gewählten Interpreter und --project <absoluter-projekt-pfad> aus. Es kopiert die gebündelte Engine in .collab/collab_engine.py und fügt /.collab/ zur .gitignore des Projekts hinzu. Es initialisiert das Ledger nicht und ersetzt keine andere vorhandene Engine. Führe ein separates Upgrade durch, falls es sich weigert.
Die folgenden Befehle werden vom Projektstamm aus ausgeführt. Ersetze python3 bei Bedarf durch den gewählten Interpreter. Prüfe bei Git-gestützten Aufgaben zuerst, ob das Projekt ein Git-Repository mit einem Basis-Commit und einer konfigurierten Git-Identität ist. Verwende den tatsächlichen Basis-Branch mit --base-branch <branch>, wenn es nicht main ist.
Besitz vor dem Bearbeiten herstellen
- Führe
Statusaus. Trete dem initialisierten Workspace mit einer eindeutigen Kollaborateur-ID bei; erhalte den Projektschlüssel über den autorisierten lokalen Kontext des Benutzers. Verwende für einen neuen WorkspaceInitFreshmit dem gewählten Lead und einem Projektschlüssel. Halte den Schlüssel und die lokale Sitzung aus Git heraus. - Füge eine Aufgabe mit den beabsichtigten Dateipfaden und Abhängigkeiten hinzu, falls sie nicht existiert.
- Führe vor dem Bearbeiten
SilentHandshakeaus. Ein BUSY_REDIRECT ist eine Verweigerung, diese Aufgabe zu beanspruchen; wähle eine alternative berechtigte. Verwende--use-worktreefür gleichzeitige Branch-gestützte Aufgaben, die dasselbe Projekt teilen. - Setze Checkpoints für sinnvolle Fortschritte. Verwende bei Eigentumsübergaben
AtomicHandoff; der empfangende Agent führtCheckOrContinueaus. Ein Agent, der übergeben hat, muss SKIP_ALREADY_HANDED_OFF respektieren. - Führe
Doneaus, wenn die Implementierung fertig ist, und lasse dann einen anderen Agenten den gepinnten Commit überprüfen. Eine echte Überprüfung bedeutet, die Änderungen und relevanten Prüfungen zu inspizieren, bevor das Urteil abgegeben wird.
Respektiere den Umfang des Benutzers und die bestehende Autorisierung für Commits, Uploads, Merges und Releases. Die Zustimmung eines Peers autorisiert für sich genommen keine externe Veröffentlichung. Sende keine Nachrichten an andere Agenten oder Personen ohne Autorisierung; Übergabeaufzeichnungen können vom nächsten Agenten beim Ausführen konsumiert werden.
Engine-Befehle
Stelle jeder Zeile python3 .collab/collab_engine.py --local-path . voran. Gib wo zutreffend eine stabile --collaborator-id <agent> an.
| Aktion | Argumente und Verhalten |
|---|---|
InitFresh | --project-key <key> --collaborator-id <lead>; verweigert ein vorhandenes Ledger. |
JoinExisting | --project-key <key> --collaborator-id <agent> --device-cluster-id <cluster> --same-device true für Zusammenarbeit auf demselben PC. |
Status / Tasks | Besitz, Fortschritt und Lieferung inspizieren. Status akzeptiert --render-format CLI oder Markdown. |
AddTask | --task-id T1 --task-title "Funktion implementieren" --files src/feature.py; optional --depends-on T0. |
SilentHandshake | --task-id T1 --collaborator-id <owner> --git-branch; optional --use-worktree. |
Checkpoint | --task-id T1 --collaborator-id <owner> --commit-message "checkpoint: sinnvoller Fortschritt"; optional --push. Committed aktuell besessene Dateien. |
ReleaseFiles | --task-id T1 --collaborator-id <owner> --files <pfade> für absichtliche Claim-Freigabe. |
AtomicHandoff | --task-id T1 --collaborator-id <owner> --target-agent-id <empfänger> --reason "Implementierung fortsetzen"; Kontext hinzufügen mit --last-prompt, --changes-summary, --remaining-todo; optional --push. |
CheckOrContinue | --task-id T1 --collaborator-id <agent>; die Übergabe laden oder die Resume-Skip-Sperre respektieren. |
Done | --task-id T1 --collaborator-id <owner>; pinnt saubere Arbeit für die Überprüfung; optional --push. |
SubmitReview | --task-id T1 --collaborator-id <pruefer> --review-verdict APPROVED|CHANGES_REQUESTED --review-notes "Ergebnisse"; Selbstüberprüfung ist blockiert. |
ReopenTask | --task-id T1 --collaborator-id <owner-or-lead> um ausstehende oder zurückgesetzte Arbeit zu überarbeiten. |
MergeTask | --task-id T1 --collaborator-id <agent> --squash; versucht einen Push. Verwende --use-worktree, um den gemeinsamen Checkout einer anderen Aufgabe zu erhalten; --reapply wendet zurückgesetzte Arbeit explizit erneut an. |
ReleaseTag | --tag v1.0.0 --tag-message "Meilenstein akzeptiert" --collaborator-id <agent>; taggt den verifizierten Basis-Branch und versucht einen Upload. |
RevertTask | --task-id T1 --collaborator-id <agent>; erstellt einen Undo-Commit; optional --push und --use-worktree. |
RecoverTag | --tag v1.0.0 --recovery-branch recover/v1.0.0 um von einem Meilenstein abzuzweigen. |
ResolveRecovery | Nur auflösen, nachdem der betroffene Checkout repariert wurde. --abandon-recovery archiviert das Journal und listet manuelle Reparaturen auf; es führt diese Reparaturen nicht durch. |
SelfTest | Führt die 42-stufige Testsuite der Engine in Wegwerf-Fixtures aus. |
Bearbeite und führe Projektprüfungen für eine Branch-gestützte Aufgabe mit Worktree im aufgezeichneten worktreePath der Aufgabe aus.
Grenzen und Wiederherstellung
- Claims sind kooperative Engine-Prüfungen; Editoren und beliebige Git-Befehle können sie umgehen. Kollaborateur-IDs sind Bezeichnungen, keine authentifizierten Identitäten.
- Ein PC-Board ist die lokale Autorität. Separate PCs verwenden Branches und Git-Synchronisation; synchronisierte Board-Replikate bieten keine verteilte Sperre. Behandle einen geteilten Ordner nicht als transaktionales Ledger.
--backup-path <lokaler-synchronisierter-ordner>schreibt einen unidirektionalen Board-Snapshot. Der Sync-Client übernimmt den Cloud-Upload; die Engine hat keinen nativen Drive-, OneDrive- oder TeraBox-API-Adapter.- Die Review-Genehmigung markiert die Aufgabe als erledigt und gibt ihre Claims frei; verifiziertes Mergen/Lieferung ist eine separate Operation. Melde
DELIVERY: COMPLETEnur, wenn die Engine den Remote-Push verifiziert; behalte LOCAL_ONLY oder INCOMPLETE bei, wenn zurückgegeben. - Wenn die Wiederherstellung UNRESOLVED meldet, bewahre das Journal und die lokalen Dateien auf. Inspiziere den benannten Checkout, speichere relevante Änderungen und versuche es nach der Bereinigung erneut. Verwende Aufgabe nicht als Ersatz für das Aufbewahren von Dateien.
- ResetWorkspace archiviert das Board und erfordert eine Lead-Identität plus
--confirm-reset; verwende es nur, wenn das Zurücksetzen des Workspaces im Rahmen der Benutzeranfrage liegt.
Der Skill erfordert einen Coding-Agenten mit Dateisystem- und Shell-Zugriff. Verwende die tatsächliche Skill-Aufrufmethode des Hosts; /baton ist kein universell registrierter Terminal- oder Chatbot-API-Befehl.