amoxideDie richtigen Aliase, zur richtigen Zeit

Du arbeitest tagsüber an einem Node-Dienst und abends an einem Rust-Seitenprojekt. Der Kontextwechsel ist eigentlich klein — gleicher Editor, gleiches Terminal, gleiche Arbeitsroutine. Aber sobald du linten oder testen willst, musst du kurz nachdenken, in welcher Welt du gerade bist. Ist es npm run lint oder cargo clippy? npm run dev oder cargo run?

Die übliche Antwort sind Präfix-Aliase: nl für Node-Lint, rl für Rust-Lint. Es funktioniert, aber die Hände bauen nie echtes Muskelgedächtnis auf. Du denkst immer einen Schritt voraus — "welcher Präfix gilt hier?" — statt einfach zu tippen. Diese kleine Reibung summiert sich über den Tag.

Mit zwei amoxide-Profilen vergibst du in beiden Kontexten denselben kurzen Namen für jede Aufgabe. l ist immer Lint. t ist immer Test. b ist immer Build. r ist immer Run. Nach ein paar Tagen fühlt es sich nicht mehr wie ein Werkzeug an, sondern wie eine Gewohnheit. Der Profilwechsel — am use node oder am use rust — ist die eine Entscheidung zu Beginn einer Session.

Alle Profile liegen in ~/.config/amoxide/profiles.toml — reines TOML, versionierbar neben deinen Dotfiles.

Euer Repo hat ein Justfile mit 30-odd Rezepten: CI-Checks, Integrationstests, Datenbank-Migrationen, Staging-Deployments. Neue Teammitglieder wissen nicht, dass just existiert. Erfahrene vergessen Rezepte, die sie seit drei Wochen nicht getippt haben. Der Befehl für Integrationstests ist cargo test --features integration -- --test-threads 1 und steht nur in der CI-Konfiguration.

Jeder hat seine eigenen Shortcuts. Manche nutzen make, manche just, manche kopieren aus Slack. Das Ergebnis: Ein Team, das technisch an derselben Codebase arbeitet, aber mit völlig unterschiedlichem Muskelgedächtnis. Neue Leute verbringen die erste Woche damit zu fragen: "Wie starte ich die Tests?"

Eine .aliases-Datei im Repo-Root löst das für alle. Wenn ein Entwickler ins Projektverzeichnis wechselt, lädt amoxide sie automatisch. am ls zeigt jeden verfügbaren Shortcut — kein Fragen, kein Raten. Ändert sich ein Befehl, aktualisiert ein Commit ihn für das gesamte Team.

Die .aliases-Datei nutzt dasselbe TOML-Format wie Profile. Teams können auch Subcommand-Aliase für komplexe Aufrufe hinzufügen, die sonst nur im Kopf einzelner Personen existieren würden.

Oh-my-zsh liefert über 120 kubectl-Aliase. kgp ist get pods. kdp ist describe pod. kgpw ist get pods --watch. Das Schema wurde von jemand anderem entworfen, verwendet Abkürzungen, die du nicht gewählt hast, und lässt sich nicht anpassen, ohne das Plugin zu forken. Entweder du nimmst alle 120 oder keine.

Und die Aliase, die du wirklich brauchst, sind gar nicht dabei. kubectl logs deployment/api --since=10m --tail=100 — den du bei jedem Incident tippst — hat keinen Alias. Also tippst du ihn vollständig, oder du fügst klogs-api zu deiner .zshrc hinzu und vergisst ihn drei Wochen später, begraben neben den anderen Einzel-Shortcuts.

amoxide-Subcommand-Aliase lassen dich das Schema selbst definieren. Ein Basis-Alias leitet zu einem Befehl weiter, und kurze Subcommand-Sequenzen expandieren zu den Flags, die für dich sinnvoll sind. k get po wird zu kubectl get pods. k logs api wird genau zu dem Aufruf, den du immer brauchst. Alles liegt an einem Ort, ist mit am ls sichtbar und gehört dir — ohne fremde Konfiguration zu berühren.

Subcommand-Aliase können in einem globalen Profil (immer verfügbar) oder in einer Projekt-.aliases-Datei leben (nur aktiv in diesem Repo).

Du arbeitest mit drei Kunden. Jeder hat einen anderen Cloud-Provider, eine andere Staging-URL, eine andere Deployment-Pipeline, ein anderes VPN. Deine .zshrc enthält drei auskommentierte Blöcke, die du von Hand umschaltest, wenn du den Kontext wechselst. Der falsche deploy-Alias hat einmal zehn Minuten lang auf die falsche Staging-Umgebung gezeigt, bevor du es gemerkt hast.

Das eigentliche Problem: Globale Aliase gehören niemandem. Sie häufen sich an — alte Kunden-Shortcuts neben aktuellen, manche kaputt, manche überlagern sich gegenseitig. Alle paar Monate machst du ein Aufräumen, das einen Nachmittag dauert und sich trotzdem nie vollständig anfühlt.

Mit amoxide lebt jeder Kunde in seinem eigenen Verzeichnis. cd client-a/ lädt automatisch deren Aliase — ihren AWS-Shortcut, ihren Deploy-Befehl, ihren Staging-URL-Öffner. cd client-b/ entlädt alles und lädt deren Aliase. Nichts vermischt sich. Die .aliases-Datei für jeden Kunden kann im Projekt-Repo liegen — versioniert, nachvollziehbar, teilbar.

Projekt-Aliase erfordern einmalig am trust pro Repository — amoxide lädt keine Datei automatisch, die es noch nicht gesehen hat.

Acht Jahre Entwicklung, etwa 200 Aliase. gcm könnte git commit -m oder git checkout master sein, je nachdem, wann du ihn geschrieben hast. Manche beziehen sich auf Projekte, an denen du nicht mehr arbeitest. Manche sind kaputt, weil das Tool umbenannt wurde. alias | grep git gibt 40 Zeilen zurück und du findest trotzdem nicht den einen, den du suchst.

Der einzige Weg, einen Alias zu entdecken, ist, sich zu erinnern, dass man ihn erstellt hat. Der einzige Weg, sie aufzuräumen, ist, durch eine Datei zu scrollen, die man seit Jahren nicht vollständig gelesen hat. Du weißt, dass es gemacht werden muss. Du schiebst es immer wieder auf.

amoxide macht daraus einen handhabbaren Nachmittag. Verschiebe Aliase in benannte Profile — work, personal, git, rust, ops — jedes ein reiner TOML-Abschnitt, den du lesen, kommentieren und verstehen kannst. am ls zeigt genau, was gerade aktiv ist. Nichts wird geladen, außer du oder ein Projektverzeichnis haben darum gebeten. Aus dem 200-Alias-Haufen werden fünf Profile, denen du wirklich vertraust.

Profile können zusammen aktiviert werden: am use git work schichtet beide übereinander, wobei spätere Profile bei Namenskonflikten Vorrang haben.