agent-team

Überführe das Prinzip "mehrere Sitzungen = mehrere Abteilungen" in das Projektverzeichnis. Es handelt sich nicht um ein Rollenspiel, sondern um ein Stellen-System: Jede Sitzung hat feste Verantwortlichkeiten, Schreibgrenzen, einen Posteingang, eine Übergabe und eine Prüfschranke.

Grundlegende Grenzen

Das Projektfundament muss zur Geschäftsdomäne passen, bevor die Kollaborationsebene aufgesetzt wird. Das Standard-Zielverzeichnis ist das aktuelle Arbeitsverzeichnis. Fehlt docs/ oder eine klare Ziel-/Fortschritts-/Übergabedatei, bestimme zunächst den Projekttyp: Bei Internetprodukten / Vibe Coding wird bevorzugt vibe-project-foundation empfohlen; bei anderen Geschäftsdomänen wird ein vorhandener, domänenspezifischer Foundation-Skill oder die bestehende Dateistruktur verwendet. Wenn kein passendes Fundament existiert, frage nach dem Geschäftsziel, den Liefergegenständen, den Abnahmekriterien, den Ressourcen und den Risiken/Prüfmethoden, erstelle ein minimales Geschäftsfundament und baue dann die Kollaborationsebene auf.
Alle drei Ebenen müssen vorhanden sein: Managementebene / Ausführungsebene / Prüfebene. Das Minimal-Setup ist lead,do,review. Erzwinge keine Aufteilung in Abteilungen nur um "mehrere Agents" willen.
Vor der Erstellung von docs/collaboration/, dem Hinzufügen/Entfernen/Ersetzen von Abteilungen, der erstmaligen Erstellung von Abteilungssitzungen oder der Änderung des Cross-Session-Routings oder der Benachrichtigungsmodi muss der Benutzer zustimmen. Bereits als automatisch/manuell registrierte Kurz-Weckrufe werden gemäß Abteilungstabelle.md ausgeführt, ohne dass jedes Mal eine erneute Bestätigung erforderlich ist.
Schreibe keine Geschäftslogik direkt; dieser Skill dient ausschließlich der Team-Diagnose, dem Aufbau der Kollaborationsebene, der Sitzungsregistrierung und der Pflege der Kollaborationsregeln.
Wenn docs/collaboration/ bereits existiert, überschreibe es nicht. Lies zuerst den aktuellen Stand und entscheide dann, ob inkrementell Abteilungen hinzugefügt, Sitzungen registriert, Regeln aktualisiert oder neu aufgebaut werden soll.
Harte Schranke vor dem Start: Leite nicht automatisch von "Hilf mir, ein Team / eine Abteilung aufzubauen" auf die Internetproduktentwicklung um. Bestätige zuerst die endgültigen Liefergegenstände des Projekts und den Sitzungserstellungsmodus, bevor du Abteilungen empfiehlst.

Betriebsregeln

Diese Regeln müssen in die Generierungsausgabe geschrieben werden, und bei der späteren Aufgabenverteilung ist Folgendes zu beachten:

Drei-Knoten-Prüfschranke: Jede Funktion / jeder Schritt wird nur durch einen Abnahmeknoten vorangetrieben. Nach Abschluss eines Abteilungsknotens wird zuerst an die Koordinationsabteilung berichtet. Die Koordinationsabteilung entscheidet nach den drei Kategorien: Produktwahrnehmung / wichtige Grenzknoten müssen vom Benutzer bestätigt werden, prozessuale/technische Knoten können eigenständig vorangetrieben werden, Knoten, die eigenständig vorangetrieben werden können, aber die Projektsichtbarkeit beeinflussen, müssen mit einer kurzen Knotenkarte gemeldet werden.
Der Posteingang ist die Quelle der Wahrheit: Aufgabendetails und Berichte werden in das Posteingang.md der entsprechenden Abteilung geschrieben. Jede Abteilungssitzung registriert beim Amtsantritt / bei der Übergabe nur einmal ihre Benachrichtigungsfähigkeit; anschließend wird nach dem registrierten "automatischen/manuellen" Modus verfahren. Benachrichtigungen zeigen nur drei Status an: neue Aufgabe / Aufgabe abgeschlossen / Blockade aufgetreten.
Vierer-Set des Abschlussberichts: Ausgabepfad, Verifikationsergebnis (inkl. nicht verifizierter Punkte), Logbeleg, Fehler-Selbstkontrolle. Fehlt eines davon, kann die Koordinationsabteilung den Abschluss nicht als geschlossen betrachten.
Koordination frisst keinen langen Kontext: Die Koordinationsabteilung liest zuerst ihren eigenen Posteingang und prüft nur die Existenz des Logbelegs. Nur bei unzureichenden Berichten, fehlerhaften Belegen, widersprüchlichen Abteilungsschlussfolgerungen oder auf Benutzeranfrage wird der minimal notwendige Haupttext gelesen.
Prüfebene unabhängig bedeutet nicht ausreichende Blindprüfung: Die Prüfabteilung verifiziert selbst, übernimmt nicht den langen Kontext der Ausführungsabteilung und vertraut nicht auf die Aussage "bereits bestanden". Sie darf aber auch nicht einfach den Happy Path der Ausführungsabteilung wiederholen. Alles, was der Benutzer sieht / Eingabeaufforderungen / Fehlermeldungen / Fortschritt / Status / Popups / Ergebniszusammenfassungen / exportierte Dateinamen / Build-Fenster betrifft, muss am Worker / UI / letztem Benutzerausgang getestet werden; Tests nur auf Engine/API/Helper-Ebene gelten nicht als bestanden. Für jedes kritische Risiko muss mindestens eine Reverse-Sonde entworfen werden.
Aufgabenverteilung muss Abnahme-Exit und Pflicht-Fehlerpfade enthalten: Die Koordinationsabteilung muss beim Verteilen von Aufgaben den Abnahme-Exit und die Pflicht-Fehlerpfade angeben. Der Abnahme-Exit bezeichnet den Ort, an dem der Benutzer letztendlich das Ergebnis / die Eingabeaufforderung / den Fehler / den Status / das Popup / die Ergebniszusammenfassung / den exportierten Dateinamen / das Build-Fenster sieht. Bei benutzersichtbaren Inhalten darf nicht nur die Engine/API/Helper-Ebene angegeben werden. Die Pflicht-Fehlerpfade listen mindestens 1-3 Fehler-, Ausnahme- oder Grenzszenarien auf, die den Happy Path durchbrechen. Fehlen sie, fordert die empfangende Abteilung die Koordinationsabteilung zur Vervollständigung auf und füllt sie nicht selbst aus.
Erfahrung vor Test: Funktionale Features werden dem Benutzer zuerst zur Erfahrung gegeben. Wenn der Knoten "Benutzer muss App erleben" erreicht ist, öffnet die Koordinationsabteilung standardmäßig direkt die App für den Benutzer, ohne vorher zu fragen "Soll ich die App öffnen?", und gibt eine kurze Erfahrungskarte. Erst nach der expliziten Bestätigung des Benutzers "Erfahrung OK / kann in den Test gehen" führt die Testabteilung die professionelle Qualitätskontrolle durch.
Designabsicht muss visualisiert werden: Bei Knoten, die UI, Interaktion, visuelle Darstellung, Seitenlayout, Designentwürfe oder Benutzererfahrungspfade betreffen, darf die Designabteilung nicht nur Textbeschreibungen, ASCII-Wireframes, Markdown-Tabellen oder abstrakte Schlussfolgerungen liefern. Sie muss eine Designabsichtsvorschau liefern, die der Benutzer direkt beurteilen kann. Die Designvorschau darf nicht behaupten, der echten App-UI zu entsprechen; die echte UI-Abnahme erfolgt anhand der laufenden App / des echten Routings / Build- oder Build-Fenster-Screenshots.
Designbestätigung unabhängig von Funktionsbestätigung: Die Bestätigung des Benutzers, dass die Funktionsrichtung OK ist, ist nicht gleichbedeutend mit der Bestätigung der visuellen/interaktiven Gestaltung. Bevor der Benutzer die Designrichtung (visuell/interaktiv) bestätigt hat, darf die Koordinationsabteilung die Entwicklungsabteilung nicht mit der formellen Implementierung beauftragen; es dürfen maximal Funktionsmachbarkeit oder technische Bewertungen vorangetrieben werden.
Blindprüfung/Stichprobenprüfung erfolgt bei Auslösung: Wenn dieselbe Funktionskette mehrere Runden ohne Blockade durchläuft (Standard 3 Runden, anpassbar mit Begründung), die Kette über Engine→Worker→UI→Benutzerausgang verläuft, hohe Risiken wie Fehlermeldungen/Status/Release/Packaging/Sicherheit/Kosten betroffen sind, oder der Benutzer/Koordinator die Begründungsbasis für unzureichend hält, wird eine Sub-Agent-Blindprüfung/Stichprobenprüfung ausgelöst. Der Sub-Agent berichtet nur die Schlussfolgerung der Blind-/Stichprobenprüfung, ändert nicht direkt Code und gibt nicht automatisch frei.
Risiko/Kosten erfolgt bei Auslösung: Die Sicherheitsabteilung greift nur in großen Phasen, vor dem Go-Live/Versand oder bei Risiken wie Datenschutz, Berechtigungen, Schlüsseln, Autorisierung, Drittanbieterplattformen, Produktionskonfigurationen ein. Die Finanzabteilung greift nur an Kostenknoten ein, warnt nur und blockiert nicht den Release.
Freigabe entscheidet der Benutzer: Nach bestandener dreistufiger Prüfung gibt die Koordinationsabteilung nur eine Freigabeempfehlung. Markierung als abgeschlossen, externer Versand, Bezahlung usw. werden vom Benutzer bestätigt.
Routing-Merkregel: Klärungsanfragen (keine Änderung von Ergebnissen, keine Entscheidungen, keine Fortschrittsänderung) gehen direkt in den Posteingang des Empfängers; Änderungen / Entscheidungen / Statusänderungen / Freigaben / Hinzufügen/Entfernen von Abteilungen erfolgen über die Koordinationsabteilung.
Aufteilung bei nicht bestandenem Test: Nachdem der Benutzer die Erfahrung als OK bestätigt hat, geht es in den Test. Stellt die Testabteilung reine Code-/Qualitäts-/Ausnahmepfad-Probleme fest, schreibt sie zurück an die Koordinationsabteilung. Die Koordinationsabteilung verwendet zuerst eine Knotenkarte, um den Benutzer zu informieren, und kann dann der Entwicklungsabteilung eigenständig Nacharbeit zuweisen. Nur bei Fragen der Erfahrungsabwägung, Bereichsänderung, Kosten/Sicherheit/Release, Lösungsauswahl oder wesentlichen Angelegenheiten wird angehalten und auf Benutzerbestätigung gewartet.

Drei-Knoten-Entscheidung der Koordinationsabteilung

Das Entscheidungsprinzip der Koordinationsabteilung:

Der Benutzer ist verantwortlich für Produkterfahrung, Funktionsentscheidungen, Designurteile und wesentliche Risikoentscheidungen; die Koordinationsabteilung ist verantwortlich für technische Abläufe, Abteilungssteuerung, routinemäßige Qualitätssicherung und unumstrittene Fortschritte. Eigenständige Fortschritte müssen einen kurzen Bericht behalten; bei Produktwahrnehmung oder wesentlichen Grenzänderungen muss angehalten und bestätigt werden.

A. Muss vom Benutzer bestätigt werden

Alle Knoten, die die Produkterfahrung, Benutzerwahrnehmung, Funktionsentscheidungen, UI-Design, Interaktionsabläufe, visuelle Darstellung, MVP-Grenzen, Produkt-Roadmap, Release, externen Versand, deutliche Kostenerhöhung, Datenschutz-/Sicherheits-/Cloud-/Schlüssel-/Autorisierungsrisiken betreffen, müssen von der Koordinationsabteilung angehalten und vom Benutzer bestätigt werden.

Typische Fälle:

Nach Abschluss einer Funktion muss der Benutzer sie selbst erleben.
Nach Fertigstellung von UI / Interaktion / Designentwurf muss dem Benutzer eine visuelle Vorschau gezeigt werden.
Enthält die Designabteilung nur Textbeschreibungen, ASCII-Wireframes, Markdown-Tabellen oder abstrakte Schlussfolgerungen, gilt der Designknoten nicht als abgeschlossen.
Hat der Benutzer nur die Funktionsrichtung als OK bestätigt, aber nicht die visuelle/interaktive Richtung, darf nicht in die formelle Entwicklungsimplementierung eingestiegen werden.
Wenn Funktionen hinzugefügt, entfernt, zurückgestellt oder deren Umfang geändert werden soll, muss der Benutzer entscheiden.
Ob nach bestandenem Test formell abgeschlossen und in die nächste große Phase eingetreten wird, muss der Benutzer bestätigen.
Wenn Cloud, Upload, API-Key, Online-Download, Kosten, Paketgrößenänderung betroffen sind, muss der Benutzer bestätigen.

B. Koordination kann eigenständig vorantreiben

Alle prozessualen/technischen Knoten, die der Benutzer nicht beurteilen kann und die die Produkterfahrung und wesentliche Grenzen nicht verändern, kann die Koordinationsabteilung nach fachlichem Ermessen vorantreiben, ohne wiederholt nachfragen zu müssen.

Typische Fälle:

Nach Bestätigung der Produktgrenzen wird die Designabteilung mit der Erstellung eines minimalen Interaktionsentwurfs beauftragt.
Nach Fertigstellung des Designentwurfs wird die Entwicklungsabteilung mit einer Umsetzungsbewertung beauftragt.
Nach Bestätigung des visuellen/interaktiven Designs durch den Benutzer und klarer, risikoarmer technischer Bewertung wird die Entwicklungsabteilung mit der formellen Implementierung beauftragt; vor Bestätigung der UI darf nur die Umsetzungsbewertung / technische Machbarkeit vorangetrieben werden.
Nach OK-Erfahrung des Benutzers wird die Testabteilung mit der Qualitätskontrolle beauftragt.
Stellt die Testabteilung nach OK-Erfahrung des Benutzers reine Code-/Qualitäts-/Ausnahmepfad-Probleme fest, informiert die Koordinationsabteilung per Knotenkarte und beauftragt die Entwicklungsabteilung mit Nacharbeit.
Bei keinen P0/P1/P2-Blockaden im Test kann die Koordinationsabteilung eine Durchgangsempfehlung geben und in die Abschlussbestätigung gehen.
Routineaufgaben wie Logging, Übergabe, gemeinsame Fehlersammlung, Fortschrittsaufzeichnung, leichte Verifikation, Commit-Archivierung nach Benutzerbestätigung des Abschlusses.

C. Kann eigenständig vorangetrieben werden, muss aber berichtet werden

Diese Knoten erfordern keine Entscheidung des Benutzers, aber die Koordinationsabteilung muss dem Benutzer mit einer kurzen Knotenkarte mitteilen: "Ich bin bis zu diesem Schritt vorangekommen".

Knotenkartenbeispiel:

"Entwicklungsbewertung abgeschlossen, aber UI nicht bestätigt; ich habe die Entwicklung nur mit der technischen Machbarkeitsbewertung beauftragt."
"Visuelles/interaktives Design bestätigt und Entwicklungsrisiko kontrollierbar; ich habe die Entwicklung mit der formellen Implementierung beauftragt."
"Nachdem du die Erfahrung als OK bestätigt hast, habe ich die Testabteilung mit der Qualitätskontrolle beauftragt."
"Test hat Code-Ebene-Probleme gefunden, die keine Produktentscheidungen betreffen; ich habe die Entwicklungsabteilung mit Nacharbeit beauftragt."
"Test ohne Blockade; ich bereite den Abschluss und die Archivierung vor."
"Sicherheit/Finanzen wurden bei diesem Knoten nicht ausgelöst, daher nicht eingegriffen."

Abnahme-Exit, Fehlerpfade und Blind-/Stichprobenprüfung

Die Koordinationsabteilung muss bei der Aufgabenverteilung "wo wird abgenommen" und "wie wird der Happy Path gebrochen" in die Aufgabe schreiben, nicht nur ein abstraktes Abnahmeziel.

Pflichtfelder bei Aufgabenverteilung:

Abnahme-Exit: Wo der Benutzer letztendlich das Ergebnis / die Eingabeaufforderung / den Fehler / den Status / das Popup / die Ergebniszusammenfassung / den exportierten Dateinamen / das Build-Fenster sieht. Bei benutzersichtbaren Inhalten darf nicht nur die Engine / API / Helper-Ebene angegeben werden.
Pflicht-Fehlerpfade: Mindestens 1-3 Fehler-, Ausnahme- oder Grenzszenarien zum Durchbrechen des Happy Path.

Fehlt eines davon, fordert die empfangende Abteilung die Koordinationsabteilung zur Vervollständigung auf und füllt es nicht selbst aus.

Pflichtfelder im Prüf-/Testbericht:

Verifikationsebene: Engine / Adapter-Service / Worker-Hintergrundaufgabe / UI-Benutzersichtbarer Ausgang / Build-Status / Nicht abgedeckte Ebenen.
Benutzersichtbarer Ausgang: Der tatsächlich getestete Endausgang.
Reverse-Sonden aus dem Design: Mindestens eine pro kritischem Risiko, die zeigt, wie bewiesen wird, dass nicht nur der Happy Path wiederholt wurde.
Nicht abgedeckte Ebenen: Ebenen, die nicht abgedeckt wurden, müssen explizit genannt werden; wenn keine, schreibe "Keine".
Sub-Agent-Blind-/Stichprobenprüfung ausgelöst?: Auslöseschlussfolgerung und Begründung.

Prüfebene unabhängig bedeutet nicht ausreichende Blindprüfung. Die Prüfabteilung darf nicht einfach den Happy Path der Ausführungsabteilung wiederholen. Alles, was der Benutzer sieht / Eingabeaufforderungen / Fehlermeldungen / Fortschritt / Status / Popups / Ergebniszusammenfassungen / exportierte Dateinamen / Build-Fenster betrifft, muss am Worker / UI / letztem Benutzerausgang getestet werden; Tests nur auf der unteren Ebene gelten nicht als bestanden.

Auslösebedingungen für Blind-/Stichprobenprüfung:

Dieselbe Funktionskette durchläuft mehrere Runden ohne Blockade, Standard 3 Runden, anpassbar gemäß Projektbeschreibung.
Kette verläuft über Engine→Worker→UI→Benutzerausgang.
Betrifft Fehlermeldungen, Status, Release/Packaging, Sicherheit, Kosten oder andere hohe Risiken.
Benutzer oder Koordinator hält die Begründungsbasis für unzureichend.

Nach Auslösung berichtet der Sub-Agent nur die Schlussfolgerung der Blind-/Stichprobenprüfung, ändert nicht direkt Code und gibt nicht automatisch frei.

Aufteilung bei nicht bestandenem Test

Die Benutzererfahrung der App ist bestanden, was nur bedeutet, dass der Erfahrungsablauf, die Funktionserwartungen und die Benutzerwahrnehmung in den professionellen Test eingehen können; es bedeutet nicht, dass Codequalität, Ausnahmepfade, Build-Status, Logging oder Grenzbedingungen bereits bestanden sind. Stellt die Testabteilung P0/P1/P2 oder andere Qualitätsprobleme fest, schreibt sie zuerst einen Prüfbericht und [Bericht] an den Posteingang der Koordinationsabteilung. Die Koordinationsabteilung muss zuerst mit einer Knotenkarte die Schlussfolgerung an den Benutzer übermitteln und dann die Probleme nach Art aufteilen:

Eigenständige Beauftragung der Entwicklungsabteilung mit Nacharbeit: Reine Code-Bugs, Ausnahmepfade, Fehlermeldungen, Logging, Build-Status, Inkonsistenzen an Worker/UI-Ausgängen, Testabdeckungslücken und andere professionelle Qualitätsprobleme; diese Probleme erfordern kein Code-Urteil des Benutzers.
Anhalten und auf Benutzerbestätigung warten: Änderung der Produkterfahrung, des Funktionsumfangs, des Designs, der MVP-Grenzen, der Datenaufbewahrungsstrategie, der Kosten, der Sicherheit, des Datenschutzes, der Release-Methode oder es gibt mehrere Reparaturmöglichkeiten, die die Erfahrung / den Umfang / die Kosten / die Geschwindigkeit beeinträchtigen würden.

Die Knotenkarte muss klar angeben: Testschlussfolgerung, Auswirkungen, Nacharbeitsgrund, ob eine Benutzerentscheidung erforderlich ist, Koordinationsbewertung, nächster Schritt. Eigenständige Nacharbeit bedeutet nur Eintritt in den Reparaturkreislauf, nicht endgültige Freigabe. Nach der Reparatur wird zum Benutzererfahrungs-/Testknoten zurückgekehrt.

Abschluss und Commit-Archivierung

Übergabe ist nicht gleich Git-Commit. Die Abteilung aktualisiert bei Knotenabschluss zuerst die Übergabe, das Log, den Posteingangsbericht und die erforderlichen Ergebnisse; der Commit ist die Archivierungsaktion im Versionsrepository nach der formellen Bestätigung des Abschlusses durch den Benutzer.

Wenn keine P0/P1/P2-Blockaden im Test und keine Blockaden bei Risiko-/Kostenknoten vorliegen, kann die Koordinationsabteilung eine Freigabeempfehlung geben und den Benutzer um formelle Abschlussbestätigung bitten. Nach Bestätigung des Benutzers führt die Koordinationsabteilung Folgendes aus:

Führe git status --short aus.
Wenn das Arbeitsverzeichnis nur Änderungen enthält, die zu diesem Knoten gehören, führe den Commit zur Archivierung aus.
Wenn nicht verwandte Änderungen, nicht bestätigte Änderungen oder nicht zuordenbare Änderungen vorhanden sind, erkläre dies dem Benutzer zuerst und mische sie nicht in den Commit.
Wenn das Projekt kein Git-Repository ist, erkläre, dass ein Commit nicht möglich ist, und führe nur die Abschlussaufzeichnung auf der Kollaborationsebene durch.

Commit-Archivierung bedeutet nicht externen Release; Release, externer Versand, Bezahlung, Go-Live werden weiterhin vom Benutzer entschieden.

App-Erfahrungsknoten

Wenn der Knoten "Benutzer muss App erleben" erreicht ist, öffnet die Koordinationsabteilung standardmäßig direkt die App für den Benutzer, ohne vorher zu fragen "Soll ich öffnen?". Wenn die App in der aktuellen Umgebung gestartet / geöffnet werden kann, führe es direkt aus; wenn der Start fehlschlägt, erkläre den Fehlergrund, die bereits versuchten Befehle und den manuellen Einstiegspunkt für den Benutzer.

Standard für die Erfahrungskarte:

Einstieg:
Schwerpunkt:
Empfohlene Vorgehensweise:
Beurteilungskriterium:

Anforderungen an die Erfahrungskarte:

Einstieg: Sage dem Benutzer, wo er einsteigen soll, z. B. "Sprachaufnahme/Stimme klonen → IndexTTS2 Emotions-Sprachaufnahme → Emotionsintensität".
Schwerpunkt: Sage dem Benutzer, worauf er sich diesmal konzentrieren soll, nenne nur 1-2 Schwerpunkte.
Empfohlene Vorgehensweise: Gib 2-4 konkrete Aktionen vor, damit der Benutzer nicht selbst überlegen muss, wie er testen soll.
Beurteilungskriterium: Sage dem Benutzer, er solle nur mit "Erfahrung OK" antworten oder angeben, was nicht rund läuft.

Beispiel:

Einstieg: Sprachaufnahme/Stimme klonen → IndexTTS2 Emotions-Sprachaufnahme → Emotionsintensität
Schwerpunkt: Höre, ob die drei Stufen deutlich und natürlich sind.
Empfohlene Vorgehensweise:
- Teste "Fröhlich" + "Zurückhaltend" / "Standard" / "Deutlich".
- Teste, ob "Lebendige Ansage" standardmäßig "Fröhlich" + "Deutlich" verwendet.
- Wechsle zu "Natürlich" und prüfe, ob es auf "Standard" festgelegt wird und einen Hinweis gibt.
Beurteilungskriterium: Wenn es sich gut anfühlt, sag "Erfahrung OK"; wenn nicht, sag mir konkret, wo es hakt.

Design-Visualisierungsbestätigungsknoten

Bei Knoten, die UI, Interaktion, visuelle Darstellung, Seitenlayout, Designentwürfe oder Benutzererfahrungspfade betreffen, muss die Designabteilung eine Designabsichtsvorschau liefern, die der Benutzer direkt beurteilen kann. Sie darf nicht nur Textbeschreibungen, ASCII-Wireframes, Markdown-Tabellen oder abstrakte Schlussfolgerungen liefern. Die Designabsichtsvorschau dient der Beurteilung von Richtung, Layout, Informationshierarchie und Interaktionsgefühl und darf nicht behaupten, der echten App-UI zu entsprechen.

Die echte UI-Abnahme muss von der laufenden App, dem echten Routing, dem Build-Artefakt oder Build-Fenster-Screenshots erfolgen. Elemente wie OpenDesign / Figma / HTML-Mock / PNG der Designabteilung dienen nur als Grundlage für die Designabsicht; die Entwicklungsabteilung muss nach der Implementierung die Abweichungen von der Designabsicht kennzeichnen, und die Testabteilung prüft anhand der echten App-Oberfläche, ob Abweichungen vorliegen.

Priorität der Designabteilung für die Lieferung:

Verwende bevorzugt spezielle Design-Tools wie OpenDesign, um bearbeitbare Design-Artefakte oder Artifacts zu generieren.
Wenn die aktuelle Sitzung OpenDesign MCP nicht hot-geladen hat, kein aktives Projekt in OpenDesign vorhanden ist, die Berechtigungen unzureichend sind oder die Tool-Verbindung fehlschlägt, muss die Designabteilung im Bericht den genauen Fehlergrund angeben.
Wenn das Tool nicht verfügbar ist, muss mit lokalen HTML + PNG-Screenshots, Figma, öffnbarer Bildvorschau oder ähnlichem abgesichert werden, damit der Benutzer die Designabsicht sieht. Es darf jedoch nicht versprochen werden, dass dies die endgültige echte UI ist.
Wenn der Benutzer OpenDesign nicht installieren, starten, autorisieren, registrieren oder reparieren möchte oder die Sitzung nicht neu laden / öffnen möchte, darf die Designabteilung nicht blockieren. Sie soll gemäß den Benutzerpräferenzen direkt lokales HTML + PNG, Figma oder eine öffnbare Bildvorschau wählen.

Der "Ausgabepfad" im Vierer-Set des Abschlussberichts der Designabteilung muss gleichzeitig enthalten:

Pfad zum Designbeschreibungsdokument.
Pfad zur Designabsichtsvorschau, z. B. OpenDesign-Artefakt-Link / lokales HTML / PNG-Screenshot / Figma-Link / öffnbares Bild.
Wenn ein Fallback-Plan verwendet wird, muss der aktuelle Status von OpenDesign und die Bedingungen für die Wiederherstellung klar beschrieben werden.

Regeln für die OpenDesign-Integration:

Stelle zuerst sicher, dass die lokale OpenDesign-App läuft, und überprüfe dann den Daemon-Status.
Gehe nicht davon aus, dass der Standard-Port 7456 ist; bestätige die tatsächliche Daemon-URL anhand der OpenDesign-Logs oder des lokalen Listening-Ports.
Registriere nach der Bestätigung den open-design MCP bei Codex. Die aktuelle Sitzung kann möglicherweise keine neuen MCPs hot-laden; weise den Benutzer gegebenenfalls auf das Neuladen / Öffnen einer neuen Sitzung hin.
Wenn der OpenDesign-Artefakt-Schreibvorgang auf ein fehlendes aktives Projekt hinweist, fordere den Benutzer auf, in OpenDesign ein Projekt zu erstellen oder darauf zu klicken, oder verwende direkt lokales HTML / PNG als Fallback. Blockiere den Knoten nicht.
Wenn festgestellt wird, dass OpenDesign nicht installiert / nicht läuft, die Berechtigungen unzureichend sind, die Verbindung fehlschlägt oder der MCP nicht hot-geladen wurde, muss die Designabteilung den Benutzer aktiv fragen, ob er Hilfe bei der Installation / dem Start / der Autorisierung / der MCP-Registrierung / dem Neuladen der Sitzung benötigt. Wenn der Benutzer nicht reagiert, sofort den Fallback-Visualisierungsplan verwenden.
Minimale Fehlerbehebungsreihenfolge: Prüfen, ob die App läuft → Listening-Port oder Daemon-URL in Logs prüfen → Prüfen, ob der MCP registriert / in der aktuellen Sitzung hot-geladen ist → Aktives Projekt prüfen → Berechtigungen / Verbindungsfehler prüfen. Bei jedem Schritt bei Fehler sofort den Fallback-Vorschauplan anbieten.
OpenDesign dient nur zur Verbesserung der Designausdrucks- und Visualisierungsbestätigungsfähigkeit. Es bedeutet nicht, dass es automatisch zu einem vollständigen UI-Redesign, einem Marken-Upgrade oder einer Entwicklungsimplementierung erweitert wird.

Nach Erhalt des Designberichts geht die Koordinationsabteilung wie folgt vor:

Zeige zuerst die Designabsichtsvorschau an, dann gib dem Benutzer eine kurze Knotenkarte.
Empfohlene Struktur der Knotenkarte: Ergebnis / Beurteilungspunkt / Vorschlag / Risiko / Nächster Schritt.
Wirf dem Benutzer keine langen technischen Erklärungen oder Design-Haupttexte zur Beurteilung hin.
Bevor der Benutzer die Designrichtung (visuell/interaktiv) bestätigt hat, darf die Entwicklungsabteilung nicht mit der formellen Implementierung beauftragt werden. Wenn der Benutzer nur die Funktionsrichtung als OK bestätigt, aber die UI nicht bestätigt hat, dürfen nur Funktionsmachbarkeit oder technische Bewertungen vorangetrieben werden.
Nach Abschluss der Entwicklung darf die UI-Beurteilung nicht weiterhin die Designabsichtsvorschau als Ersatz für die echte Oberfläche verwenden. Es muss zur echten App / zum echten Routing / zu Build- oder Build-Fenster-Screenshots zurückgekehrt werden.

Bedingung für Stopp des eigenständigen Fortschritts

Eigenständiger Fortschritt der Koordination bedeutet nicht unbegrenzten, kontinuierlichen Fortschritt. Prozessuale Knoten können kontinuierlich vorangetrieben werden, aber in folgenden Fällen muss angehalten und der Benutzer gefragt werden:

Die Schlussfolgerung ist offensichtlich unsicher.
Es gibt widersprüchliche Beurteilungen zwischen Abteilungen.
Es müssen Erfahrung, Umfang, Kosten oder Geschwindigkeit geopfert werden.
Neue Abhängigkeiten, Cloud, Online-Konnektivität, Modelle oder Kosten müssen hinzugefügt werden.
Die zuvor vom Benutzer bestätigte Produktrichtung muss geändert werden.
Es muss in eine ausführbare Funktionserfahrung, UI-Visualisierungsbestätigung, Release/Packaging/externen Versand oder den großen Phasenabschluss eingetreten werden.

Diagnoseprozess

Wenn der Benutzer bereits den Projekttyp, die Liefergegenstände und den Sitzungserstellungsmodus klar angegeben hat, diagnostiziere direkt; frage nicht wiederholt. Bei unzureichenden Informationen stelle nur eine Schlüsselfrage pro Mal.

Erste Frage:

Was ist das letztendliche Liefergegenstand dieses Projekts: Ausführbare Software, Inhalt/Kurs, Betriebsergebnis, Rechercheplan, Automatisierungsprozess, physische Lieferung oder etwas anderes?

Zweite Frage:

Wie werden die Sitzungsabteilungen erstellt: Werden sie automatisch von einem Agenten mit Sitzungsverwaltungstool wie Codex erstellt, oder erstellst du zuerst manuell die einzelnen Abteilungssitzungsfenster und ich bin nur für die Generierung der Abteilungsdateien und die Einarbeitung zuständig?

Bevor die erste Frage nicht beantwortet ist, darf nicht das übliche Software-Setup product/design/dev/test empfohlen werden. Bevor die zweite Frage nicht beantwortet ist, darf nicht behauptet werden, dass Abteilungssitzungen erstellt wurden. Wenn dem Projekt Fundamentdateien fehlen, muss zuerst beurteilt werden, ob ein anwendbarer domänenspezifischer Foundation-Skill existiert; wenn nicht, erstelle ein allgemeines minimales Geschäftsfundament. Leite nicht alle Projekte zu vibe-project-foundation.

Bei der Diagnose werden immer drei Ebenen angenommen. Beurteile nur, wie viele Abteilungen auf der Ausführungsebene und wie viele auf der Prüfebene erforderlich sind:

Auslösedimension	Auswirkung bei Treffer	Abteilungen
Software / Internetprodukt / Vibe Coding / ausführbares Ergebnis	Software-Setup aktivieren	`product/design/dev/test`
Starke UI/Interaktion/visuelle Darstellung	Design verstärken	`design`
Starke Datensammlung, Benutzer-/Markt-/Wettbewerbs-/Faktenprüfung	Forschung hinzufügen	`research`
Starke Planung, Prozesse, Zeitpläne, Ressourcenallokation	Planung hinzufügen	`planning`
Starke Datenerfassung/-bereinigung/-import/-export/-genauigkeit	Daten hinzufügen	`data`
Batch-Verarbeitung, zeitgesteuert, plattformübergreifend automatisiert	Automatisierung hinzufügen	`auto`
Kontinuierliche Produktion von Texten/Bildern/Videos/Berichten	Inhalt hinzufügen	`content`
Wachstum, Conversion, Bindung, kommerzieller Betrieb	Wachstum/Betrieb hinzufügen	`growth`
Konten, Login, Datenschutz, Compliance, Drittanbieterplattformen, Schlüssel, Produktionskonfiguration	Risikoprüfung öffnen	`security`
Budget, kosten sensitiv, kostenpflichtige Artikel	Kostenprüfung öffnen	`finance`
Komplexe Funktionalität, benötigt Bug/Ausnahmeabdeckung	Unabhängige Qualitätsprüfung	`test` oder `review`
Nichts stark ausgeprägt	Allgemeines Minimal-Setup	`lead,do,review`

Bei Nicht-Software-Projekten nicht zwingend das Produkt/Design/Entwicklung/Test-Setup aufzwingen. Beurteile zuerst anhand der Liefergegenstände, Abnahmekriterien, Prozessressourcen, Risiken und Prüfmethoden. Wenn keine Zuordnung möglich ist, verwende lead,do,review und ergänze bei Bedarf research/planning/content/data/auto/security/finance je nach Risiko.

Fundamentauswahl

Die Kollaborationsebene ist auf ein Projektfundament angewiesen, das es den Abteilungen ermöglicht, Ziele und Grenzen zu verstehen. Das Fundament ist jedoch nicht gleichbedeutend mit einer festen Software-Verzeichnisstruktur.

Verarbeitungsreihenfolge:

Prüfe zuerst, ob im Projekt bereits ein nutzbares Fundament existiert: z. B. docs/, Geschäftsplan, Projektspezifikation, Lieferliste, Fortschritts-/Übergabedateien, branchenspezifische Verzeichnisse. Wenn vorhanden, plane die Abteilungszuständigkeiten und Schreibbereiche basierend auf dem vorhandenen Fundament. Erzwinge keine Umstellung auf eine Software-Struktur.
Nur bei Internetprodukten, Software, Vibe Coding oder eindeutigen Artefakten wie app/ design/ docs/spec.md wird vibe-project-foundation bevorzugt empfohlen oder verwendet.
Bei Nicht-Software-Projekten wie Kursen, Inhalten, Betrieb, Beratung, physischer Lieferung, Recherche, internen Prozessen suche zuerst nach einem entsprechenden domänenspezifischen Foundation-Skill oder einer vorhandenen Vorlage. Wenn vorhanden, verwende diese.
Wenn kein spezifisches Fundament existiert, bleibe nicht bei "Bitte installiere zuerst ein Software-Fundament" stehen. Frage zuerst nach dem Geschäftsziel, den endgültigen Liefergegenständen, den Abnahmekriterien, den Prozessressourcen, den Risiken/Prüfmethoden und erstelle dann ein minimales Geschäftsfundament.

Das minimale Geschäftsfundament enthält nur die allgemeinen Dateien, die die Kollaboration unterstützen:

docs/overview.md: Projektziel, Liefergegenstände, Zielgruppe/Nutzer, Grenzen.
docs/progress.md: Aktuelle Phase, abgeschlossen, in Arbeit, nächste Schritte.
docs/agent-guide.md: Kollaborationsregeln, Dateiaufteilung, Hinweise für dieses Projekt.
Erstelle bei Bedarf geschäftsbezogene Verzeichnisse wie deliverables/, materials/, research/, operations/, scratch/. Erstelle keine irrelevanten Software-Verzeichnisse.

Bei der Team-Empfehlung angeben:

Welche Abteilungen auf den drei Ebenen und die Begründung für die Auswahl.
Verantwortlichkeiten, Verbote, Eingaben, Ausgaben, Schreibbereiche und Verbotsbereiche jeder Abteilung.
Abteilungsübergreifendes Routing: Klärung direkt oder über Koordination.
Welche Knoten vom Benutzer bestätigt werden müssen.
Sitzungserstellungsmodus: Automatische Sitzungserstellung oder Manuelle Sitzungserstellung sowie die entsprechenden Ausführungsschritte.

Vor der Erstellung anhalten und bestätigen:

Ich empfehle, docs/collaboration/ mit der obigen Teamkonfiguration zu erstellen, Sitzungsmodus: [Automatische Erstellung / Manuelle Erstellung]. Bestätigst du das?

Erstellung der Kollaborationsebene

Nach der Bestätigung führe das Skript aus. Wenn kein spezifisches Fundament vorhanden ist und der Benutzer bestätigt, dass dieser Skill das minimale Geschäftsfundament ergänzen soll, füge --create-minimal-foundation --allow-without-foundation hinzu. Standard-Minimal-Setup:

python3 <skill-Verzeichnis>/scripts/scaffold_team.py "<Zielprojektverzeichnis>" \
  --profile "<Team-Diagnosezusammenfassung>" \
  --session-mode "manual"

Bei einer detaillierten Diagnose werden Rollen explizit übergeben:

python3 <skill-Verzeichnis>/scripts/scaffold_team.py "<Zielprojektverzeichnis>" \
  --profile "Software + starke Daten + Datenschutz/Plattform + Budget" \
  --roles "lead,product,design,dev,data,test,security,finance" \
  --session-mode "auto"

Optionale Rollen:

Managementebene: lead
Ausführungsebene: do/research/planning/product/design/dev/data/auto/content/growth
Prüfebene: review/test/security/finance

Das Skript erstellt docs/collaboration/README.md, Abteilungstabelle.md, Sitzungsstartliste.md, Routingregeln lesen.md, Fehlersammlung.md, Aufgabenübergabevorlage.md, Spezielle Schlussfolgerungen/, scripts/agent_team_read.py und unter Abteilungen/<Abteilungsname>/ die Stellenbeschreibung.md, Einarbeitung.md, Übergabedokument.md, Posteingang.md, Berichte/, Logs/<ISO-Woche>.md. Die Prüfebene erhält auch den kompatiblen alten Namen Prüfberichte/ (semantisch = Prüfbericht). Das Skript weigert sich, eine vorhandene Kollaborationsebene zu überschreiben, doppelte Rollen zu erstellen oder ein neues Team ohne Management-, Ausführungs- und Prüfebene zu erstellen. Wenn --session-mode auto/manual nicht übergeben wird, wird abgebrochen, um die Umgehung der Sitzungsmodusbestätigung zu verhindern.

Sitzungserstellungsmodi

Automatische Sitzungserstellung (Codex / mit Sitzungsverwaltungstool)

Nach Bestätigung des Benutzers für den automatischen Modus:

Führe zuerst das Skript aus, um docs/collaboration/ zu erstellen.
Verwende tool_search, um nach den drei Sitzungstools create_thread, send_message_to_thread, set_thread_title zu suchen; Anheften und Sortieren sind nicht erforderlich.
Wenn die Tools verfügbar sind, erstelle eine Sitzung für jede Abteilung. Verwende einen numerischen Präfix im Titel, um die Reihenfolge beizubehalten, z. B. 01 Koordination, 02 Produkt, 03 Entwicklung.
Sende die Einarbeitung.md jeder Abteilung als Initialisierungsnachricht an die entsprechende Sitzung. Fordere die Sitzung auf, zuerst die Aufgaben zu übernehmen und nur über Verantwortlichkeiten / Phase / in Arbeit / Posteingang / zu klärende Probleme zu berichten, ohne sofort Geschäftsaufgaben zu erledigen.
Schreibe die zurückgegebenen Sitzungs-IDs in docs/collaboration/Abteilungstabelle.md und registriere den Benachrichtigungsmodus als automatisch. Falls das Senden fehlschlägt, ändere den Benachrichtigungsmodus dieser Abteilung auf manuell und informiere den Benutzer, dass die automatische Sitzungserstellung nicht abgeschlossen wurde.
Berichte dem Benutzer abschließend: Welche Sitzungen wurden erstellt, welche Sitzungs-IDs wurden registriert, welche vom Benutzer manuell bearbeitet werden müssen.

Wenn die Tools nicht verfügbar sind oder der Aufruf fehlschlägt, sage nicht "Sitzungen wurden erstellt". Schließe stattdessen im manuellen Modus ab.

Manuelle Sitzungserstellung (andere Agents / ohne Sitzungsverwaltungstool)

Nach Bestätigung des Benutzers für den manuellen Modus:

Führe nur das Skript aus, um docs/collaboration/ und die Dateien für jede Abteilung zu erstellen.
Rufe keine Sitzungstools auf und behaupte nicht, Sitzungen erstellt zu haben.
Gib eine manuelle Startliste aus: Pfad zur Einarbeitung.md jeder Abteilung, empfohlener Fenstername, erster Satz, den der Benutzer an diese Sitzung senden soll.
Die Sitzungs-IDs in docs/collaboration/Abteilungstabelle.md bleiben als noch zu registrieren, der Benachrichtigungsmodus bleibt als noch zu registrieren oder wird gemäß Benutzerangabe auf manuell gesetzt.
Nachdem der Benutzer die Fenster manuell erstellt hat, sende die Einarbeitung.md jeder Abteilung an die entsprechende Sitzung. Die Abteilungssitzung führt zuerst python3 docs/collaboration/scripts/agent_team_read.py onboard --dept [Abteilungsname] aus, liest dann die Stellenbeschreibung, die Übergabe, die Fehlersammlung und den Posteingang gemäß den vom Skript zurückgegebenen Pflichtdateien. Danach werden alle Übergaben in das Posteingang.md des entsprechenden Abteilungsverzeichnisses geschrieben.

Prüfung nach der Erstellung:

docs/collaboration/-Struktur ist vollständig, alle drei Ebenen haben mindestens eine Abteilung.
docs/agent-guide.md wurde um die Multi-Session-Kollaborationsbeschreibung ergänzt.
docs/collaboration/Sitzungsstartliste.md enthält den automatischen/manuellen Modus und den Starteinstieg für jede Abteilung.
Im automatischen Modus enthält Abteilungstabelle.md die tatsächlichen Sitzungs-IDs und Benachrichtigungsmodi; im manuellen Modus wurde klar darauf hingewiesen, dass die Sitzungen noch nicht erstellt wurden.
docs/progress.md dokumentiert die Erstellung der Kollaborationsebene, die Teamkonfigurationszusammenfassung und die nächsten Schritte.
git status --short. Wenn es nur Änderungen im Zusammenhang mit dieser Kollaborationsebene gibt, kann ein separater Commit durchgeführt werden:

git add docs/agent-guide.md docs/progress.md docs/collaboration
git commit -m "chore: Multi-Session-Kollaborationsebene aufgebaut"

Wenn das Repository andere nicht festgeschriebene Änderungen enthält, mische sie nicht in den Commit und informiere den Benutzer.

Wartungsmodus

Später müssen möglicherweise Abteilungen hinzugefügt/zusammengelegt/entfernt, Sitzungen ersetzt, Sitzungs-IDs registriert, Grenzen angepasst, Aufgaben verteilt oder unabhängige Prüfungen durchgeführt werden. Grundsätze:

Lies zuerst docs/collaboration/Abteilungstabelle.md, um die vorhandenen drei Ebenen und Abteilungen zu bestätigen.
Beurteile, ob die Bedingung "mindestens eine pro Ebene" oder die Aufgabengrenzen verletzt werden.
Bei Hinzufügen/Entfernen/Ersetzen von Abteilungen, abteilungsübergreifenden Nachrichten, Freigaben, Nacharbeiten, Status-Upgrades muss zuerst der Benutzer bestätigen.
Verwende zum Hinzufügen einer Abteilung scaffold_team.py <Projekt> --add-roles "<IDs>". Das Skript erstellt nur die fehlenden Abteilungen und ergänzt die Abteilungstabelle. Die betroffenen Weiterleitungsregeln müssen dennoch manuell synchronisiert werden.
Beim Entfernen/Zusammenlegen von Abteilungen protokolliere zuerst die laufenden Angelegenheiten und die Historie in den Logs, aktualisiere dann die Abteilungstabelle und die entsprechenden Stellenbeschreibungen. Lösche keine Historie direkt.
Benachrichtigungsfähigkeitsregistrierung erfolgt nur einmal beim Amtsantritt / bei der Übergabe:
- Lies den "Benachrichtigungsmodus" der eigenen Abteilung in Abteilungstabelle.md. Wenn er bereits als automatisch oder manuell registriert ist, führt diese Sitzung die nachfolgenden Benachrichtigungen gemäß diesem Modus aus, ohne jedes Mal die Tools neu zu erkunden.
- Wenn der Benachrichtigungsmodus noch zu registrieren ist, suche mit tool_search nach Sendetools wie send_message_to_thread. Wenn kein tool_search vorhanden ist oder keine Sendetools gefunden werden, registriere als manuell.
- automatisch: Nachfolgende Benachrichtigungen verwenden standardmäßig direkt das Sitzungs-Sendetool für kurze Weckrufe, ohne vorherige Fähigkeitsprüfung.
- manuell: Nachfolgende Benachrichtigungen geben standardmäßig direkt einen kopierbaren Kurzweckruf an den Benutzer aus, der ihn bittet, die Zielabteilung manuell zu erinnern.
- Wenn der automatische Modus tatsächlich fehlschlägt, falle für diesen Fall auf manuelle Erinnerung zurück und bitte den Benutzer, die Koordinationsabteilung zu informieren, damit sie Abteilungstabelle.md aktualisiert.
- Wenn der Benutzer eine Änderung der Agent-Tool-Fähigkeiten feststellt, soll der Benutzer die Koordinationsabteilungssitzung informieren, die den Benachrichtigungsmodus in Abteilungstabelle.md aktualisiert.
Lese-Routing hat Vorrang:
- Neue Abteilungssitzungen oder Übergaben führen bevorzugt python3 docs/collaboration/scripts/agent_team_read.py onboard --dept [Abteilungsname] aus, damit das Skript die eigene Identität, den Benachrichtigungsmodus, die Pflichtdateien und die Standard-Lesegrenzen zurückgibt.
- Berichte, Prüfberichte, spezielle Schlussfolgerungen und wichtige Entscheidungen verwenden YAML-Frontmatter mit type / department / target / status / date / related_task / decision / tags / summary. Das Skript gibt nur diese manuell vorgegebenen Felder zurück und erstellt keine kreativen Zusammenfassungen.
- Führe vor dem Lesen von Beweisen bevorzugt agent_team_read.py find --type audit_report --status blocked, agent_team_read.py find --type special_conclusion --tag 用户可见出口 oder agent_team_read.py meta <Pfad> aus. Nur bei unzureichenden Zusammenfassungen, pathologischen Pfaden, widersprüchlichen Schlussfolgerungen, Freigabe/Nacharbeit/Sicherheit/Kosten/Release/benutzersichtbarer Qualität, Benutzeranfrage nach Beweisen oder wenn die aktuelle Aufgabe explizit vom Haupttext abhängt, wird der minimal notwendige Haupttext gelesen.

AidenXu-1/agent-team-skill

Was ist agent-team-skill?

In Ihrer bevorzugten KI fragen

Dokumentation