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 grösste Fehler bei Custom Commands ist ueberladene Magie. Ein guter Slash-Command macht etwas klar Begrenztes: diff zusammenfassen, Risiken markieren, Testlücken benennen, ein Rollout-Signal gegen echte Plattformdaten prüfen oder einen Plan für die nächste Umsetzungsrunde erzeugen. Sobald ein Command zehn implizite Dinge gleichzeitig tut, verliert er genau den Vorteil, für den er gebaut wurde: Wiederholbarkeit.
Start-Commands für Routinearbeit
Routinebefehle wie Planentwurf, Ticket-Zusammenfassung oder ein erster Risikoabriss sollten standardmässig auf quantenram-start/* liegen. So bleiben sie günstig genug, um oft genutzt zu werden, ohne dass du jede Kleinigkeit auf eine Premiumlane schiebst.
Coding-Commands für Umsetzung
Commands für Refactoring, Diff-Erklärung oder Testgerüste gehören meist auf quantenram-coding/*. Hier zählt Durchsatz und die enge Verbindung zu Tool-Loops, nicht maximale Premiumtiefe für jeden einzelnen Schritt.
Zenmaster nur für klare Review-Fälle
Commands wie /review-pr oder ein finaler Release-Check dürfen auf quantenram-zenmaster/* gehen, wenn Architektur, Risiko oder Entscheidungsschärfe 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 für QuantenRam wichtig. Ein Command ist nicht abgeschlossen, nur weil Text entstanden ist. Erst wenn der dazugehörige 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 Plätzen wie ticket, path, pr oder model. Dadurch lassen sich Runs später 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, Änderungen reviewen und die erwartete Kosten- und Tierwirkung dokumentieren. Wenn ein ehemals günstiger Routinebefehl plötzlich standardmässig auf Zenmaster zeigt, ist das keine Kleinigkeit, sondern eine operative Produktentscheidung. Genau deshalb gehören Command-Definitionen in denselben Review-Kreis wie andere Workflowkonfigurationen.
Für 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 verständlich, wenn sich Rollen, Modelle oder konkrete Tools später ändern. So bleiben Commands ueber längere Zeit wiederverwendbar.
Ein guter QuantenRam-Command ist klein, modellbewusst und verifizierbar: Start für Routine, Coding für Umsetzung, Zenmaster nur für echte Review- oder Entscheidungsarbeit.