Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Flexible Bedingungssprache für Ziele, Prompts und Aufträge. Übersetzt Bedingungen, Zeitpunkte und Reihenfolge-Abhängigkeiten in prüfbare Gates, damit ein Teilschritt erst nach belegter Freigabe ausgeführt wird. Immer verwenden bei /condition, /if, /if-only, /when, /after, /and oder /or sowie bei Formulierungen wie "erst wenn", "sobald", "nur falls", "nachdem", "warte bis", "danach" oder "vorher nicht". Auch verwenden, wenn mehrere Teilziele voneinander abhängen oder ein Goal eine spätere Freigab
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-02 | ✗→✓ | ▲ Improved | 62% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 45% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 42% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 156% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 50% | 0% |
<img src="banner.png" width="100%" alt="condition banner">
Fließtext-Bedingungen leicht übersehen. Deshalb jede relevante Bedingung in ein benanntes, prüfbares Gate übersetzen:
> Beim Lesen großzügig, beim Belegen unnachgiebig.
Die Eingabe darf natürlichsprachlich und unvollständig sein. Die interne Übersetzung muss dagegen eindeutig festhalten:
Nur den betroffenen Teilschritt sperren. Unabhängige Arbeit fortsetzen.
| Ausdruck | Semantik | Beispiel | | --- | --- | --- | | /condition <Bedingung> -> <Schritt> | Kanonisches Gate | /condition Tests grün -> Release bauen | | /if <Bedingung> -> <Schritt> | Synonym für /condition | /if Review abgeschlossen -> mergen | | /when <Bedingung> -> <Schritt> | Ausführen, sobald die Bedingung eintritt | /when Export fertig -> Bericht prüfen | | /if-only <Bedingung> -> <Schritt> | Nur bei Erfüllung; sonst gar nicht ausführen | /if-only Backup belegt -> Altbestand löschen | | /after <Dauer> -> <Schritt> | Zeitversatz ab dem Setzzeitpunkt | /after 30 minutes -> Status prüfen | | /and | Alle verknüpften Bedingungen müssen gelten | /if Tests grün /and Review da -> mergen | | /or | Mindestens eine Bedingung genügt | /if Freigabe da /or Notfallregel aktiv -> starten |
Nummerierte Bedingungen wie /condition 1 ... und /condition 2 ... verwenden, wenn ein Prompt mehrere Gates enthält. Bei gemischtem /and und /or keine stillschweigende Operatorrangfolge erfinden: Klammern oder nummerierte Teilbedingungen verwenden. Bei weiterhin mehrdeutiger Bedeutung nachfragen, bevor ein riskanter Schritt freigegeben wird.
/if-only als Verbot behandeln. Kann die Bedingung nicht belegt werden, den Schritt nicht ausführen. Bei unklarer Formulierung und irreversiblen Folgen die strengere Lesart wählen.
Die Eingabe in einen prüfbaren Satz übersetzen. Relative Zeiten beim Setzen in einen absoluten Zeitpunkt mit Zeitzone umrechnen.
| Eingabe | Normalisierte Bedingung | Belegklasse | | --- | --- | --- | | time 06:00 | Systemzeit ist mindestens 06:00 in der vereinbarten Zeitzone | Uhr-/Zeitwerkzeug | | after 2 hours | Systemzeit ist mindestens Setzzeitpunkt plus zwei Stunden | Uhr-/Zeitwerkzeug | | wenn Worker A fertig ist | Abnahmeartefakt oder Taskstatus von A zeigt Abschluss | Task-/Dateiwerkzeug | | wenn Tests grün sind | Vorgeschriebener Testlauf endet erfolgreich | Prozess-/Testwerkzeug | | nach dem Push | Ziel-Remote enthält den vorgesehenen Commit | Versionskontrollwerkzeug | | wenn der User zustimmt | Explizite Zustimmung liegt in der Konversation vor | Nutzereingabe |
Ist kein objektiver Belegweg erkennbar, das offen benennen. Kein Gate so formulieren, dass es nur durch Vermutung geschlossen werden kann.
Wenn ein persistenter Gate-, Task- oder Memory-Store verfügbar ist, dort mindestens diese Felder speichern:
textid condition blocks mode = wait | only proof_method status = open | met | dropped created_at evidence
Existiert kein persistenter Store, den Zustand sichtbar im aktuellen Goal, Taskplan oder Übergabedokument führen. Nur dann behaupten, dass ein Gate Sessions überlebt, wenn der verwendete Speicher tatsächlich dauerhaft ist.
Ein vorhandener Runtime-Adapter darf andere Befehlsnamen verwenden. Funktional braucht er: open, list, meet und drop oder gleichwertige Operationen.
Ein offenes Gate blockiert nicht den gesamten Auftrag. Alle unabhängigen Schritte ausführen und vor dem nächsten abhängigen Schritt den Gate-Zustand erneut prüfen.
Nicht aktiv in kurzen Agentenschleifen pollen. Für längere Wartezeiten einen Scheduler, Hintergrundjob oder ein Ereignis verwenden, das bei Eintritt einmalig meldet. Nach dem Wecksignal die eigentliche Bedingung trotzdem erneut mit dem vorgesehenen Werkzeug belegen.
Erst die Werkzeugabfrage ausführen, dann das Gate mit konkreter Evidenz schließen. Geeignete Belege sind zum Beispiel:
Eine Schätzung, ein erwarteter Zustand oder die bloße Behauptung eines anderen Workers genügt nicht, wenn ein unabhängiger Beleg verfügbar sein sollte.
Ist ein Gate durch Auftragsänderung hinfällig, es mit Begründung als dropped markieren. Bei /or die nicht mehr benötigten Alternativen ebenfalls schließen oder verwerfen, damit keine Zombie-Gates verbleiben.
Wenn alle unabhängigen Schritte erledigt sind:
übergeben.
Keine zusätzliche Berechtigung aus einer Bedingung ableiten. Ein erfülltes Gate ändert nur die Reihenfolge; es erweitert nicht den autorisierten Umfang des Auftrags.
textZiel: Daten prüfen und Bericht veröffentlichen. /condition time 16:00 Europe/Berlin -> Veröffentlichung starten
Die Datenprüfung darf vorher stattfinden. Die Veröffentlichung bleibt gesperrt, bis eine aktuelle Zeitabfrage mindestens 16:00 Uhr belegt.
text/condition 1 Tests erfolgreich /condition 2 Review freigegeben /if condition 1 /and condition 2 -> mergen
Beide Gates getrennt belegen. Erst danach mergen.
text/if-only verifiziertes Backup vorhanden -> alte Dateien löschen
Ohne belegtes Backup nichts löschen und das offene Verbot im Abschlussbericht nennen.
/if-only wie ein bloßes Warten behandeln./or nicht mehr benötigte Alternativ-Gates offen lassen./and-//or-Verknüpfungen, dauerhafte Zustände und Autorisierungsgrenzen geklärt./condition, /if, /if-only, /when, /after, /and und /or.Other measured skills in the registry, with their headline benchmark lift.