Custom Commands als wiederholbare QuantenRam-Operatoren definieren
Commands sind dann stark, wenn sie nicht nur Textbausteine speichern, sondern einen kleinen, reproduzierbaren Workflow kapseln. In QuantenRam sollten sie deshalb immer an ein bewusstes Aliastier, klar benannte Eingaben und einen nachvollziehbaren Verify-Schritt gebunden sein.
Der groesste Fehler bei Custom Commands ist ueberladene Magie. Ein guter Slash-Command macht etwas klar Begrenztes: diff zusammenfassen, Risiken markieren, Testluecken benennen, ein Rollout-Signal gegen echte Plattformdaten pruefen oder einen Plan fuer die naechste Umsetzungsrunde erzeugen. Sobald ein Command zehn implizite Dinge gleichzeitig tut, verliert er genau den Vorteil, fuer den er gebaut wurde: Wiederholbarkeit.
Start-Commands fuer Routinearbeit
Routinebefehle wie Planentwurf, Ticket-Zusammenfassung oder ein erster Risikoabriss sollten standardmaessig auf quantenram-start/* liegen. So bleiben sie guenstig genug, um oft genutzt zu werden, ohne dass du jede Kleinigkeit auf eine Premiumlane schiebst.
Coding-Commands fuer Umsetzung
Commands fuer Refactoring, Diff-Erklaerung oder Testgerueste gehoeren meist auf quantenram-coding/*. Hier zaehlt Durchsatz und die enge Verbindung zu Tool-Loops, nicht maximale Premiumtiefe fuer jeden einzelnen Schritt.
Zenmaster nur fuer klare Review-Faelle
Commands wie /review-pr oder ein finaler Release-Check duerfen auf quantenram-zenmaster/* gehen, wenn Architektur, Risiko oder Entscheidungsschaerfe im Vordergrund stehen. Genau diese Bindung sollte aber explizit im Command stehen und nicht versteckt im Hintergrund passieren.
Slash-Commands mit Modell, Parametern und Verify definieren
Die beste Command-Definition nennt immer vier Dinge: Zweck, Modell, Eingabeform und Abschlussbedingung. Wenn eine Person den Befehl liest, sollte sofort erkennbar sein, was hinein geht, welcher QuantenRam-Pfad genutzt wird und woran man einen erfolgreichen Lauf erkennt. Die konkrete Syntax kann je nach Client leicht abweichen; die Struktur bleibt dieselbe.
{
"commands": {
"review-pr": {
"description": "Bewertet einen PR auf Risiken, Testluecken und Rollback-Punkte",
"model": "quantenram-zenmaster/gpt-5.4",
"args": ["pr", "scope"],
"steps": ["analysiere diff", "bewerte risiko", "pruefe testluecken"],
"verify": ["python manage.py check", "pytest -q"]
}
}
}Gerade der Verify-Block ist fuer QuantenRam wichtig. Ein Command ist nicht abgeschlossen, nur weil Text entstanden ist. Erst wenn der dazugehoerige Check, Test oder Plattform-Smoke-Request erfolgreich ist, wird aus einem Prompt ein belastbarer Workflow.
Parameter und Optionen bewusst klein halten
Parameter sollten explizit benannt sein und eine begrenzte Form haben. Statt einen riesigen Freitextcontainer zu erwarten, arbeitet ein guter Command lieber mit klaren Plaetzen wie ticket, path, pr oder model. Dadurch lassen sich Runs spaeter besser vergleichen, dokumentieren und in Teamnotizen wiederfinden. Wenn ein Command viele freie Felder braucht, ist er oft kein guter Command, sondern ein halbfertiger manueller Workflow.
{
"commands": {
"draft-plan": {
"model": "quantenram-start/deepseek-chat",
"args": ["ticket", "goal"],
"fallback_model": "quantenram-coding/qwen3codernext"
}
}
}Commands versionieren, teilen und wiederverwenden
Ein Command-Katalog sollte wie Code behandelt werden. Das heisst: im Repo oder in einer klar versionierten Team-Konfiguration ablegen, Aenderungen reviewen und die erwartete Kosten- und Tierwirkung dokumentieren. Wenn ein ehemals guenstiger Routinebefehl ploetzlich standardmaessig auf Zenmaster zeigt, ist das keine Kleinigkeit, sondern eine operative Produktentscheidung. Genau deshalb gehoeren Command-Definitionen in denselben Review-Kreis wie andere Workflowkonfigurationen.
Fuer Teams ist ausserdem hilfreich, Commands nicht nach Personen, sondern nach Aufgaben zu benennen. Ein Name wie review-pr, ship-check oder draft-plan bleibt auch dann verstaendlich, wenn sich Rollen, Modelle oder konkrete Tools spaeter aendern. So bleiben Commands ueber laengere Zeit wiederverwendbar.
Ein guter QuantenRam-Command ist klein, modellbewusst und verifizierbar: Start fuer Routine, Coding fuer Umsetzung, Zenmaster nur fuer echte Review- oder Entscheidungsarbeit.