PureTokens/puretokens-skill

Pure Tokens Image

Verwende ausschließlich die feste Pure Tokens Images API: https://api.puretokensx.com/v1/images/generations. Bearbeitungen rufe nur mit "/v1/images/generations" oder "/v1/images/edits" auf, wenn die genaue Modelldatei dies erfordert. Verwende immer die vollständige, feste URL; verwende keine konfigurierte Basis-URL als Ziel der Anfrage und überprüfe auch nicht den Provider-Namen.

Der aktuelle Host nutzt seine vorhandene Authentifizierungs-/HTTPS-API-Fähigkeit und verwendet die Anmeldeinformationen, die mit der aktuellen Pure Tokens-Verbindung übereinstimmen, um die Anfrage durchzuführen; die Anmeldeinformationen werden nur für diese eine feste Anfrage im Speicher gehalten. Sowohl ein Drittanbieter-CC-Switch als auch eine manuelle Host-Konfiguration können als Quelle dieser Verbindung dienen. Zeige, fordere, speichere, protokolliere oder melde keine Keys, Basis-URLs, Header, vollständigen Host-Konfigurationen, Rohantworten oder Benutzermedien; verwende keine Node, MCP, Proxy, Sidecar, separaten Uploads oder alternative Endpunkte.

On-Demand-Abruf von Material

Lade nicht bei jeder Anfrage alle Modelle und alle Ausnahmeszenarien. Lies stattdessen in der folgenden Reihenfolge so wenig wie nötig:

1. Lies zuerst references/model-index.json: Analysiere das Standardmodell oder den eindeutigen Alias und ermittle den genauen Profilpfad.
2. Lies nur das Profil des ausgewählten Modells references/profiles/<model>.json: Überprüfe Parameter, Einschränkungen, Operationen und Lifecycle. Für genaue Modelle, die nicht im Index enthalten sind, sind nur die Kern-Texte-zu-Bild-Felder erlaubt; nur wenn der Benutzer zusätzliche Parameter, Referenzbilder oder Bearbeitungen anfordert, frage bei Bedarf das Live-Verzeichnis ab.
3. Normale, reine POST-Anfragen können allein auf Basis dieses Skills, des Index und des ausgewählten Profils ausgeführt werden; erst nach Erhalt der Antwort, bei Eintritt in Polling/Lieferung oder bei der Konstruktion nicht-kern-Operationen wie Bearbeitungen, lies references/execution-contract.json und references/task-receipt.json.
4. Nur wenn eine entsprechende Ausnahme, Mehrdeutigkeit, Ablehnung, ein Anhang oder ein Lieferproblem auftritt, lies das passende Szenario in references/behavior-scenarios.json.

Modelle und Anfragen

• Das Standardmodell für normale Texte-zu-Bild ist gpt-image-2; image2 ist sein einziger Alias. Wenn der Benutzer einen eindeutigen Alias angibt, verwende die Indexzuordnung; bei null oder mehreren Kandidaten liste die genauen IDs auf und bitte den Benutzer um Auswahl. Wenn der Benutzer eine genaue ID angibt, behalte diese ID bei; für normale Kernanfragen darf das Verzeichnis nicht vorab gelesen werden, um Berechtigungen oder Fähigkeiten zu überprüfen.
• Normale Anfragen senden nur einmal POST /v1/images/generations, immer mit model, prompt und async: true. Nur wenn das genaue Profil es angibt, werden n, size, image_size, aspect_ratio, width, height, strength oder andere optionale Felder und Werte übermittelt.
• Eine Benutzeranfrage kann nur eine einzige kostenpflichtige Aufgabe erstellen; niemals aufteilen. n muss vom Profil ausdrücklich erlaubt sein; ansonsten erkläre, dass jeweils nur ein Bild unterstützt wird oder bitte den Benutzer, ein Modell zu wählen, das diese Anzahl unterstützt.
• Physische Größen wie "200cm × 230cm" dürfen nicht an die API übergeben werden. Erkläre, dass physische Größen nicht exakt garantiert werden können, und liste die tatsächlich im Profil deklarierten Pixelgrößen, semantischen Größen oder Seitenverhältnis-Optionen auf. Wenn width und height als Paar deklariert sind, aber eines fehlt, brich ab; wenn mehrere Größenausdrücke gleichzeitig angegeben werden, reiche nur einen gemäß der Priorität des Profils ein.
• Nur wenn der Benutzer explizit nach dem aktuellen Modell fragt, die benötigten Parameter/Operationen nicht im lokalen Profil enthalten sind, der Anhang-Transport nicht kompatibel ist oder die API aufgrund von Modell/Parameter/Fähigkeit ablehnt und eine Erklärung benötigt wird, lies einmal GET https://api.puretokensx.com/v1/media/models ab. Ein Fehler beim Lesen des Verzeichnisses darf eine ansonsten legitime Kern-Texte-zu-Bild-Anfrage nicht verhindern und löst auch keine automatischen Wiederholungsversuche aus.

Referenzbilder und Bearbeitungen

• Wenn der Benutzer ein Bild anhängt, aber keine Verwendung angibt, frage zuerst, ob es als visuelle Referenz oder als zu bearbeitendes Bild dient; nicht raten.
• Akzeptiere für öffentliche Web-Bilder nur ausdrücklich vom Benutzer bereitgestellte, konforme https:// URLs, und platziere sie nur in den vom Profil deklarierten Feldern und Transporten. Lade sie nicht herunter, untersuche sie nicht, speichere sie nicht um, schreibe sie nicht um oder generiere URLs.
• Lokale Bildreferenzen oder Bearbeitungen müssen durch die image_edit-Multipart-Operation des ausgewählten Profils ausdrücklich unterstützt werden; verwende strikt deren Pfad, Felder, Anzahl und multipart_file-Transport. Sende nur den aktuellen Anhang mit dieser einen Images-API-Anfrage; lade ihn nicht auf R2 hoch, rufe keine separaten Upload-Schnittstellen auf, generiere keine Datei-IDs, schreibe den Anhangsinhalt nicht in Prompts um und führe kein stilles Downgrade auf Texte-zu-Bild durch.
• Bei Referenzbildern bleibt die Absicht "Referenz" im Prompt erhalten; bei Bearbeitungsprompts wird klar formuliert, "was geändert werden soll und was erhalten bleibt". Masken, transparente Hintergründe, nicht deklarierte Multi-Referenzbilder und andere nicht deklarierte Erweiterungen werden vor der Abrechnung gestoppt und die Einschränkung erläutert.

Asynchrone Aufgaben und Lieferung

• Maximal einmal POST pro neuer Anfrage. Wenn das POST beginnt, aber kein analysierbares Ergebnis oder keine Aufgaben-ID liefert, melde das Ergebnis als unbekannt: Keine Wiederholung, kein Modellwechsel, keine Behauptung, dass nichts erstellt, nichts abgebucht oder nichts erstattet wurde. Bei fehlender Aufgaben-ID muss jede nachfolgende neue Anfrage die ausdrückliche Bestätigung des Benutzers einholen.
• Beziehe die Aufgaben-ID nur aus den deklarierten Top-Level-Feldern oder dem Top-Level-task_id/id; frage nur dieselbe https://api.puretokensx.com/v1/images/{task_id} ab und liefere nach Erfolg in der Reihenfolge content?index=0..n-1 aus. URLs, Statustexte, HTML, SVG gelten nicht als erfolgreiche Lieferung.
• Jedes Polling-Fenster hat maximal 6 Statusabrufe und maximal 120 Sekunden; normale Wartezeiten sind 3, 6, 12, 24, 30 Sekunden. Bei 429 wird nur fortgesetzt, wenn ein gültiger Retry-After weiterhin innerhalb des aktuellen Budgets für dieselbe Aufgabe liegt. Kein Hintergrund-Polling, keine gleichzeitigen Statusabrufe, keine automatischen Wiederholungen.
• Melde Erfolg nur, wenn der Host tatsächlich native Bildbytes oder Anhänge liefert. Liefere Bild für Bild aus; keine Vorabrufe, keine wiederholten Lesevorgänge, kein Caching von Benutzermedien; beende die aktuelle Antwort nach Erfolg.

Fehlerquittungen

Wenn der Host vor dem POST aufgrund von Netzwerk-, Genehmigungs-, Anhang-Übergabe- oder nativen Byte-Lieferungsfähigkeiten blockiert wird, gib failure_phase: validation zurück, stelle klar, dass die Images-API nicht ausgeführt wurde, und mutmaße nicht über die Konfigurationsursache. Gib bei anderen Fehlern gemäß execution-contract.json und dem passenden Verhaltensszenario eine sichere Quittung aus: Gib nur den tatsächlich von der API zurückgegebenen HTTP-Status und den öffentlichen Fehlercode an; lege keine Rohantworten, internen URLs, Stacks, Zugangsdaten, Anfrageinhalte oder Benutzermedien offen.