agmsg Team (Modellauswahl-Entwicklung)

agmsg model-selected development

Verwenden Sie dieses Skill, um ein aufgabenbezogenes Peer-Team zu bilden. Es gibt keinen permanenten Befehlshaber und keinen dauerhaft anwesenden Worker-Pool: Der Task Owner ist das Modell, das Sie für diese Sitzung ausgewählt haben (in Claude Code oder Codex). Es besitzt die Aufgabe von Anfang bis Ende und startet dann nur die Peer-Rollen, die für die begrenzte Arbeit über agmsg benötigt werden.

Requires the agmsg skill (https://github.com/fujibee/agmsg) installed, and both the claude and codex CLIs available — an agmsg team spawns peers on both. Read the installed agmsg skill before calling its scripts. Use only its provided Bash scripts; never access its database, team files, or config directly.

Team starten oder fortsetzen

Lösen Sie das Team auf, bevor Sie mit der Aufgabenarbeit beginnen. Verwenden Sie den CLI-Namen der aktuellen Sitzung (claude-code oder codex) überall dort, wo <cli> unten erscheint.

1. Wenn der Aufruf einen Teamnamen angibt, verwenden Sie genau diesen Namen. Wenn er lokal nicht vorhanden ist, erstellen/beitreten Sie es mit join.sh; wenn es existiert, überprüfen Sie seine Besetzung mit team.sh und arbeiten Sie darin. Erstellen Sie keinen lokalen Namensvetter, wenn die Anfrage darin besteht, ein entferntes Team zu pullen – folgen Sie stattdessen agmsgs Remote-Pull-Ablauf.
2. Ohne expliziten Namen führen Sie whoami.sh "$(pwd)" <cli> und team-list.sh --scope project "$(pwd)" aus. Setzen Sie das einzige Team fort, das mit diesem Projekt verbunden ist. Wenn es keines gibt, erstellen Sie ein lokales Team, benannt nach einem sicheren Kleinbuchstaben-Slug des Projektverzeichnisnamens (z.B. payments-api). Wenn mehr als eines zutrifft, fragen Sie den Benutzer, welches bestehende Team verwendet werden soll; wählen Sie niemals willkürlich.
3. Registrieren Sie den Task Owner mit join.sh <team> <agent> <cli> "$(pwd)", wenn nötig. Wählen Sie eine ungenutzte Identität wie <team>-owner (optional modellqualifiziert, z.B. <team>-sol-owner); überprüfen Sie zuerst team.sh <team> und hängen Sie bei Kollision eine Nummer an. Merken Sie sich das aufgelöste Team und die Agentenidentität für diese Aufgabe.
4. Überprüfen Sie den Eingang des Owners zu Beginn jeder wiederaufgenommenen Runde und vor der Deklaration des Abschlusses: inbox.sh <team> <owner>.

Der erste Aufruf erstellt daher das Standard-Projektteam, wenn kein brauchbares Projektteam existiert; ein explizit angegebenes Team gewinnt immer. Teams und Agentenidentitäten sind lokaler agmsg-Zustand, gehen Sie also nicht davon aus, dass sie zwischen Maschinen geteilt werden, es sei denn, die Remote-Synchronisierung wurde konfiguriert.

Modell-Routing

Der Task Owner (TO) kontrolliert die Modellauswahl und Eskalation. Worker geben ihre Ergebnisse oder Eskalationsanfragen an den TO zurück; sie weisen nie direkt neu zu oder geben Arbeit direkt weiter. Provider-Grenzen spielen keine Rolle, da Aufgabenkontext und Ergebnisse durch agmsg bewegt werden können.

Verwenden Sie das günstigste Modell, das die Aufgabe zuverlässig erledigen kann. Rolle definiert Verantwortung; Modell definiert die Denkfähigkeit, die für das aktuelle Ticket benötigt wird. Wählen Sie kein teures Modell, nur weil eine Rolle Consultant oder Specialist heißt.

• General — Luna: Routine-Implementierung, mechanische Änderungen, einfaches Refactoring, einfache Dokumentation und andere klare ausführungsintensive Arbeiten.
• Consultant — Terra oder Sonnet: Planung, Anforderungs-/Produktanalyse, Reviews, einfaches Design oder Architektur, moderates Debugging und Abwägungsanalyse. Wählen Sie nach Aufgabenpassung, nicht nach Provider-Präferenz.
• Specialist — Sol oder Opus: Komplexe Architektur oder UX, schwieriges Debugging und Refactoring-Design, tiefgehende Reviews, domänenübergreifendes Denken und Entscheidungen mit erheblichen nachgelagerten Auswirkungen. Keines ist der obligatorische Standard für die Rolle.
• Eskalation — Astra: Außergewöhnlich schwieriges oder risikoreiches Denken, ungelöste systemweite Probleme oder abschließende unabhängige Überprüfung, nachdem Sol oder Opus unzureichend war. Astra ist kein Standard-Specialist-Modell.

Der normale Weg ist Luna → Terra/Sonnet → Sol/Opus → Astra; der TO kann eine Stufe überspringen, wenn das Ticket dies klar rechtfertigt. Eskalieren Sie basierend auf Mehrdeutigkeit, erforderlicher Denktiefe, Kontextgröße, Fehlerkosten, vorherigen fehlgeschlagenen Versuchen oder unzureichendem Vertrauen – nicht allein aufgrund der Aufgabenwichtigkeit.

Wenn ein Worker glaubt, dass sein zugewiesenes Modell unzureichend ist, berichtet es, was etabliert ist, was ungelöst bleibt, warum der aktuelle Ansatz unzureichend ist, ob Eskalation empfohlen wird und welches zusätzliche Denken benötigt wird. Der TO entscheidet dann, ob er es erneut versucht, innerhalb der Stufe wechselt, eskaliert oder eine unabhängige Meinung anfordert.

Der Benutzer wählt das Owner-Modell vor dem Aufruf dieses Skills aus; das Skill ändert das Modell einer laufenden Sitzung nicht. Wenn das gewählte Modell unklar ist, fragen Sie den Benutzer, anstatt einen zweiten Owner zu spawnen, um zu entscheiden.

Der ausgewählte Task Owner muss Anforderungen und Abnahmekriterien festlegen, relevanten Code und Dokumentation inspizieren, nur unabhängige Arbeiten aufteilen, das Ergebnis implementieren oder integrieren, geeignete Tests durchführen und den Abschluss verifizieren. Luna ist das Standard-Delegierungsmodell für Worker, es sei denn, die Routing-Regeln rechtfertigen eine Eskalation.

Delegieren Sie frei schreibgeschützte Recherche, QA und Sicherheitsüberprüfungen, wenn sie unabhängig sind. Lassen Sie nicht zwei Peers gleichzeitig dieselbe Datei bearbeiten; partitionieren Sie Dateien oder verwenden Sie separate Git-Worktrees. Ein Task Owner ist für Ergebnisse verantwortlich, nicht dafür, jeden Schritt persönlich zu erledigen.

Verwenden Sie eine ticketförmige Nachricht. Senden Sie nur den Kontext, den der Empfänger benötigt, und zitieren Sie Dateien, Commits, Diffs oder frühere Erkenntnisse, anstatt ein anderes Modell diese wiederentdecken zu lassen. Lesen Sie Nachrichtenvorlagen, wenn Sie delegieren oder eskalieren.

Rollen und direkte Kommunikation

• Task Owner (Ihr ausgewähltes Modell): besitzt Umfang, Entscheidungen, Integration, Tests und Endprüfungen.
• Engineer / Investigator: erhält ein abgegrenztes Implementierungs- oder Recherche-Ticket und berichtet direkt an den Owner.
• Product Manager / PdM: verwenden Sie dies, wenn das Produktproblem oder die Anforderungen vor Design oder Implementierung definiert werden müssen. Klären Sie das Benutzerergebnis, den Umfang, die Priorität, die Geschäftsregeln und die Abnahmekriterien; wählen Sie keine Bildschirmstruktur, UI-Kopie oder Implementierung und bringen Sie ungelöste Produktentscheidungen an den Owner.
• Product Designer: verwenden Sie dies, wenn Produktanforderungen eine Bildschirm-/UX-Spezifikation vor der Implementierung benötigen. Definieren Sie Informationshierarchie, Abläufe, Nicht-Glückspfad-Zustände und prägnante konsistente UI-Kopie auf einem Engineer-tauglichen Niveau; ändern Sie keine Anforderungen, Geschäftsregeln, API-/Datenmodell oder Implementierungsansatz und melden Sie Anforderungslücken oder Widersprüche an den Owner.
• Accessibility Reviewer: verwenden Sie dies für bedeutende UI- oder Benutzerablauf-Änderungen, wenn eine Barrierefreiheitsprüfung erforderlich ist. Überprüfen Sie Tastaturbedienung, Fokus, Beschriftungen, Fehler- und Statusrückmeldungen, Kontrast und Anweisungen, die nur auf Farbe angewiesen sind; melden Sie Barrieren mit Beweisen und einer praktischen Behebung und bearbeiten Sie normalerweise keinen Code oder ändern Sie keine Anforderungen.
• QA: verwenden Sie dies für Verhaltensänderungen, Fehlerbehebungen, dateiübergreifende Änderungen, Regressionsrisiko, mehrere Abnahmekriterien oder bedeutende blinde Flecken des Owners. QA meldet normalerweise Ergebnisse und bearbeitet keinen Code.
• Security Reviewer: verwenden Sie dies nur für Auth/authZ, Sessions/Cookies, APIs/externe Eingaben, Uploads, Geheimnisse, DB/RLS, Infrastruktur, Abhängigkeitsaktualisierungen oder sensible Daten. Melden Sie Schweregrad, Beweise und Behebung; bearbeiten Sie normalerweise keinen Code.
• Consultant: gibt nur ein fokussiertes Urteil ab. Der Owner liefert Problem, aktuellen Zustand, Optionen, Abwägungen, Empfehlung, relevante Dateien und eine genaue Frage. Senden Sie es nicht, um das gesamte Repository erneut zu untersuchen.
• Specialist: bearbeitet ein eng definiertes schwieriges Problem nach Routing basierend auf Schwierigkeit, Unsicherheit, Fehlerkosten und vorherigen Versuchen. Wählen Sie kein Modell allein aufgrund dieses Rollentitels aus.

Jeder Worker gibt sein Ergebnis an den TO zurück. Worker können bei Bedarf direkt kommunizieren, aber sie dürfen Arbeit nicht neu zuweisen oder die nächste Rolle/das nächste Modell wählen; der TO bleibt die Routing- und Ausrichtungsinstanz.

Eskalation und Spawning

Behalten Sie den ausgewählten Owner während der gesamten Aufgabe. Eskalieren Sie nur an einem konkreten Entscheidungs- oder Fehlerpunkt; dokumentieren Sie die Antwort zurück an diesen Owner, der die Implementierungs- und Abschlussentscheidung trifft.

Bedarfsgesteuerter Lebenszyklus und Kontextwiederverwendung

Behandeln Sie jede Nicht-Owner-Rolle als bedarfsgesteuerten Worker: spawnen Sie es für ein abgegrenztes Ticket, warten Sie auf seinen Bericht, integrieren Sie das Ergebnis, dann despawnen Sie es. Halten Sie keine untätigen QA-, Sicherheits-, Consultant- oder Engineer-Prozesse zwischen Arbeitspaketen aufrecht.

spawn.sh <type> <name> --project "$(pwd)" [--team <team>] [--model <cli-model-id>] [--boot-prompt "<ticket>"] [--no-wait] [--fresh] tritt <name> vorab bei, öffnet einen tmux-Bereich (innerhalb von tmux) oder ein neues Terminal und startet die CLI. Ein claude-code-Spawn blockiert, bis sein Watcher sich verbindet; ein codex-Spawn kehrt sofort zurück, daher muss ein Codex-Peer seine Zuweisung über --boot-prompt erhalten, nicht über eine Nachricht, die gesendet wird, nachdem es untätig ist.

Um eine Rolle später in derselben Aufgabe zurückzubringen, spawnen Sie denselben Namen erneut ohne --fresh — agmsg setzt seine aufgezeichnete Sitzung fort, senden Sie also nur das Delta (Status, relevante Dateien/Commit, eine nächste Frage). Verwenden Sie --fresh nur, wenn vorheriger Kontext irreführen würde.

despawn.sh <team> <owner> <name> [--force] ist das Gegenteil von spawn und baut nur eine Rolle ab, die dieser Owner gespawnt hat. Ein sauberes despawn eines codex-Peers meldet oft "no live lock" (Codex hat keinen Watcher) - das ist normal; fügen Sie --force nur hinzu, wenn ein Terminalfenster offen gelassen wird. Despawnen Sie niemals einen handgestarteten Peer.

agmsg-Schnittstellen

Lösen Sie das scripts/-Verzeichnis des agmsg-Skills von dort auf, wo es in der aktuellen Umgebung installiert ist (sein Skill-Verzeichnis), anstatt einen festen Pfad anzunehmen, und rufen Sie dann auf:

bash <agmsg-skill-dir>/scripts/send.sh <team> <from> <to> "<structured ticket>"
bash <agmsg-skill-dir>/scripts/inbox.sh <team> <agent>
bash <agmsg-skill-dir>/scripts/team.sh <team>
bash <agmsg-skill-dir>/scripts/spawn.sh <codex|claude-code> <agent> --project "$(pwd)" --team <team> --model <installed-cli-model-id> --boot-prompt "<bounded ticket>"
bash <agmsg-skill-dir>/scripts/despawn.sh <team> <owner> <spawned-agent> [--force]

--model wird von agmsg an die installierte CLI durchgereicht. Verwenden Sie nur verifizierte lokale Modell-IDs – für Codex-Peers gpt-5.6-luna, gpt-5.6-terra, gpt-5.6-sol, gpt-6-astra; für eine andere CLI verwenden Sie ihre dokumentierte Kennung, anstatt eine zu erfinden. Ein Codex-Peer ohne Monitor-Zustellung muss seine anfängliche Zuweisung über --boot-prompt erhalten, nicht über eine Nachricht, die gesendet wird, nachdem es untätig ist.

Spawnten Sie nur, wenn es nützliche parallele Arbeit erzeugt. Bevorzugen Sie einen eng begrenzten Worker gegenüber mehreren spekulativen Workern; parallelisieren Sie nur unabhängige Tickets. Für einen handgestarteten Peer ist send.sh ausreichend. Überprüfen Sie die Besetzung vor der Zuweisung; jedes from und to muss registriert sein, es sei denn, Sie verwenden absichtlich agmsgs dokumentierte --force-Ausnahme.

Abschlussprüfung

Der ausgewählte Task Owner schließt die Aufgabe erst ab, nachdem Anforderungen und Abnahmekriterien erfüllt sind, relevante Tests bestanden wurden, ausgelöste QA- und Sicherheitsüberprüfungen abgeschlossen sind, kein Blocker mehr vorhanden ist und der Diff keine nicht zusammenhängenden Änderungen enthält. Wenn eine teure Modell-Empfehlung verwendet wurde, validieren und implementieren Sie deren Ergebnis vor dem Abschluss.