CommunityBildgithub.com

hbzheng0942/greybox-host-bridge

Leitet die Greybox-Erstellung, Gameplay-Überarbeitung und Kunst-Arbeit über die gemeinsame Python-CLI in WorkBuddy, inklusive DeepSeek-Modelle ohne Bildgenerierungswerkzeuge.

Was ist greybox-host-bridge?

Dieser Skill fungiert als eine Brücke zwischen dem AI-Agenten und dem WorkBuddy-CLI-System, speziell für die Greybox-Erstellung in Spiel-Engines wie Godot und Unity sowie für Kunst-/Bild-Workflows. Er zentralisiert alle Operationen über ein gemeinsames Python-CLI-Kommando (`python greybox.py`), wodurch der Bedarf an Node.js, MCP-Servern oder Modellwechseln entfällt. Der Skill unterstützt mehrere Arbeitsbereiche: Greybox-Erstellung/revision, Kunst-Bildgenerierung, räumliche Blender-Arbeit und S7-Modellierungsreferenzen. Er nutzt systemeigene Tool-Erkennung und CLI-Kommandos anstatt externe APIs, es sei denn, sie sind ausdrücklich konfiguriert. Der Skill enthält ein robustes Task-Kontext-System, um laufende Arbeiten bei Modellwechseln oder Übergaben zu verfolgen, und stellt sicher, dass keine bezahlten Jobs dupliziert oder geändert werden, um sie an neuere Executor-Instanzen anzupassen.

Funktioniert mit✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/hbzheng0942/grey2art/tree/main/skills/greybox-to-multistyle-art/connectors/workbuddy/skills/greybox-host-bridge

Installed? Explore more Bild skills: steipete/songsee, affaan-m/frontend-design, mattpocock/improve-codebase-architecture · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Lies {{SKILL_ROOT}}/SKILL.md für den Produktionsworkflow und dessen menschliche Entscheidungen. Verwende python "{{SKILL_ROOT}}/scripts/greybox.py" als gemeinsames Kommando-Präfix. Es wird kein Node, MCP oder Modellwechsel benötigt. Dieser Wrapper ist optional: WorkBuddy kann auch die gesamte Skill-Datei lesen und deren CLI direkt ausführen. Verwende das von setup zurückgegebene Kommando-Präfix; es zeichnet das tatsächliche Python und die verifizierte Paketidentität auf.

Für langlebige Kunstfälle verankere den tatsächlichen Eintrag im vorhandenen PLAN mittels task-context pin und fahre mit task-context run fort; lies {{SKILL_ROOT}}/references/task-context.md. Überprüfe nach einer Übergabe oder einem Modell-/Toolwechsel erneut. Melde nicht verfügbare Modell-/Schema-Fakten als unbekannt. task-context inspect unterscheidet installierte Kopien und die Legacy-/Executor-Wiederherstellungsroute jedes ursprünglichen Ledgers; erstelle niemals bezahlte Jobs neu, um sie an den neueren Executor anzupassen.

  1. Lies die aktuelle Aufgabe nach Absicht, beobachtetem Zustand und angeforderter Endstelle. Verwende intent route --file REQUEST --project PROJECT für strukturierte Anfragen-Routing. Diskussion bleibt Diskussion; Greybox-Anfragen standardmäßig zu einer Greybox-Endstelle; Fortsetzung verwendet die ursprünglichen Aufgabendatensätze. Führe host setup --host workbuddy --scope greybox --project PROJECT für Greybox-Arbeit aus, oder host setup --host workbuddy --scope art --project PROJECT --capability-report REPORT --session-id SESSION für den Kunst-/Bild-Zweig. Setup löst den tatsächlichen nativen Projektstamm auf und gibt das Kommando-Präfix zurück. Binde vorhandene systemeigene ImageGen-Aufrufevidenz ein, wenn verfügbar; dann ist kein API-Profil erforderlich. Tool-Erkennung allein reicht nicht aus. Bilddienste und nicht verwandte Werkzeuge sind keine Greybox-Voraussetzungen. Für Blender-Szenenarbeit verwende host setup --host workbuddy --scope spatial --engine blender --operation create|edit|review --project SOURCE_OR_WORKSPACE, wenn CLI-Vorbereitung benötigt wird; verfügbare native bpy/CLI/MCP-Operationen können dann der räumlichen Route folgen. Setup dient nur der Bereitschaft; die Anwendungserkennung inspiziert keine Szene. Eine rein räumliche Endstelle benötigt kein Spielprojekt oder keinen Lieferanten.

  2. Für Godot/Unity Greybox-Erstellung/-Überarbeitung lies {{SKILL_ROOT}}/references/greybox-authoring.md und verwende greybox init/build/play/validate/status/handoff; halte an der angeforderten Endstelle an. Für den Kunst-Zweig lies, wenn die Generierung fehlt, {{SKILL_ROOT}}/references/image-services.md und konfiguriere den vom Benutzer gewählten Bilddienst mit image configure. Binde dessen nicht-geheimen Namen mittels host configure --host workbuddy --image-profile NAME ein.

  3. Für neue S7-Modellierungsreferenzen lies {{SKILL_ROOT}}/references/modeling-references.md, zeichne jedes Asset und seine Ansichten einmal auf und rufe boards workbuddy start --file REGISTRY --project PROJECT --workspace WORKSPACE auf. Dies kompiliert die Seiten-Jobs und registriert/installiert deren bereichsbezogenen S7-Guard. Führe dessen exakte harmlose native Bash-Sonde aus, dann boards workbuddy bind mit dem aktuellen nativen Tool-Schema. Verarbeite die zurückgegebenen Jobs; boards workbuddy claim schreibt die exakten aufrufbereiten Argumente und reserviert die bestehende Ausgabenobergrenze. Ein geplantes Single folgt demselben Pfad und benötigt seinen berechneten oder bezogenen Grund. Zeichne das ursprüngliche Ergebnis auf, beschneide/überprüfe dann durch boards production; ein schlechter Slot löscht keine guten Geschwister, und korrigierte ROIs erzeugen Beschnittversuche ohne Neugenerierung. Ein neuer Chat erneuert die kostenlose Sonde und bewahrt ursprüngliche ausstehende Aufrufe. Für ein gewähltes Bildprofil verbrauche die exakten vorbereiteten Seitenanfragen durch das vorhandene konfigurierte Dienst-Ledger. Senke keine Qualitätsanforderungen oder reiche einen unsicheren Aufruf erneut ein.

  4. Wenn der aktive Zweig Bilder erzeugt, öffne das tatsächlich zurückgegebene lokale Bild durch das pixel-lesende Werkzeug des aktuellen Hosts. Präsentiere diese Datei mit der vom Host unterstützten Bild-UI. CLI-Erfolg begründet keine der beiden Fähigkeiten. Binde exakte aktuelle Tools und Evidenz im Sitzungsfähigkeitsbericht ein. Die Greybox-Überprüfung verwendet ihre nativen erfassten Ansichten und erfordert keine Bildgenerierung.

  5. Setze die Kommandos für die aktuelle Route und die angeforderte Endstelle fort. Liefere aus und stoppe nach der Greybox-Übergabe, wenn stop_at greybox ist; trete nur dann in die Kunst ein, wenn dies angefordert wird. Bewahre den ursprünglichen Projektzustand und die Genehmigungshistorie. Delegation ist optional; die Gleichzeitigkeit von Bild-/Modell-Mehrfachaufgaben verwendet den gemeinsamen Executor, der in {{SKILL_ROOT}}/references/execution-contract.md beschrieben ist. Native Tools bleiben agentengesteuert, es sei denn, eine tatsächliche unabhängige Brücke wird verifiziert; API-Worker können fortfahren, während die Modellverbindung stockt.

Vergleiche vor H3 das genehmigte Konzept mit dem aktuellen Ganzszenen-Proxy via scene-review --help. Bei H4 erfordern neue Produktionsverträge aktuelle Feature-/View-Vergleichsevidenz. Lies {{SKILL_ROOT}}/references/scene-comparison.md; verwende beobachtete Lücken, um Umgebung, Hauptformen, Licht und Kontakt vor der Erweiterung zu reparieren. Gültige Evidenzabdeckung ersetzt niemals die visuelle Akzeptanz des Benutzers.

Kommandos geben JSON zurück; fehlgeschlagene Kommandos geben einen Code ungleich Null zurück. Verwende für jeden Befehl --help für exakte aktuelle Optionen. Bewahre Anmeldeinformationen in der lokalen Konfiguration oder der konfigurierten Umgebung, niemals im Chat, in Connector-Dateien oder in tragbaren Projektdatensätzen. Ein Dienstausweis ist nur für den gewählten Dienst erforderlich; die Connector-Initialisierung meldet sich nicht bei einem Anbieter an oder erstellt eine bezahlte Aufgabe.

Nur wenn die aktuelle Operation Lux benötigt, führe host setup --host workbuddy --scope runtime --runtime lux aus. Es bereitet die festgelegte private Laufzeit vor/wiederverwendet sie und kann sich von einer fehlgeschlagenen venv/ensurepip-Sonde mit einem vorhandenen kompatiblen Interpreter erholen. Es fragt keine Lieferanten ab oder reicht eine Generierung ein. Bewahre den zurückgegebenen Python-Pfad über Kommandos hinweg. Ein explizites --python wird niemals stillschweigend ersetzt.

Verwandte Skills