amoxideThe right aliases, at the right time

You work on a Node service at work and a Rust side project in the evenings. The context switch between them is small — same editor, same terminal, same workflow instincts. But the moment you need to lint or run tests, you have to stop and remember which world you're in. Is it npm run lint or cargo clippy? Is it npm run dev or cargo run?

The usual answer is prefixed aliases: nl for node-lint, rl for rust-lint. It works, but it means your hands never build real muscle memory. You're always thinking one step ahead — "which prefix applies here?" — instead of just typing. That small friction compounds across a day.

With two amoxide profiles you give the same short name to each task in both contexts. l is always lint. t is always test. b is always build. r is always run. After a few days it stops feeling like a tool and starts feeling like a habit. The profile switch — am use node or am use rust — is the one decision you make at the start of a session.

All profiles live in ~/.config/amoxide/profiles.toml — plain TOML, versionable alongside your dotfiles.

Your team's repo has a Justfile with 30-odd recipes: CI checks, integration test runs, database migrations, staging deployments. New joiners don't know just exists. Veterans forget the recipe they haven't typed in three weeks. The command to run integration tests is cargo test --features integration -- --test-threads 1 and lives only in the CI config.

Everyone has their own shortcuts. Some run make, some run just, some copy-paste from Slack. The result is a team that's technically using the same codebase but working with completely different muscle memory. New people spend their first week asking "how do I run the tests?"

A .aliases file committed to the repo root fixes this for everyone. When a developer cds into the project, amoxide loads the file automatically. am ls shows every shortcut available — no asking, no guessing. When a command changes, one commit updates it for the whole team.

The .aliases file uses the same TOML format as profiles. Teams can also add subcommand aliases for complex invocations that would otherwise live only in someone's head.

Oh-my-zsh ships over 120 kubectl aliases. kgp is get pods. kdp is describe pod. kgpw is get pods --watch. The scheme was designed by someone else, uses abbreviations you didn't choose, and can't be changed without forking the plugin. You either take all 120 or you take none.

And the aliases you actually need aren't in there. kubectl logs deployment/api --since=10m --tail=100 — the one you run every incident — has no alias. So you type it in full, or you add klogs-api to your .zshrc and forget it exists three weeks later, buried next to the other one-offs.

amoxide subcommand aliases let you define the scheme yourself. A base alias routes to a command, and short subcommand sequences expand to whatever flags make sense to you. k get po becomes kubectl get pods. k logs api becomes the exact invocation you always reach for. The whole thing lives in one place, is visible with am ls, and is yours to adjust without touching anyone else's config.

Subcommand aliases can live in a global profile (always available) or a project .aliases file (only active in that repo). Cluster-specific aliases belong in the project; daily kubectl verbs belong globally.

You work with three clients. Each has a different cloud provider, a different staging URL, a different deployment pipeline, a different VPN. Your .zshrc has three commented-out blocks you toggle by hand when you switch context. The wrong deploy alias once pointed at the wrong staging environment for ten minutes before you noticed.

The deeper problem is that global aliases don't belong to anyone. They accumulate — old client shortcuts sitting next to current ones, some broken, some shadowing each other. Every few months you do a cleanup that takes an afternoon and still doesn't feel finished.

With amoxide, each client lives in its own directory. cd client-a/ loads their aliases automatically — their AWS shortcut, their deploy command, their staging URL opener. cd client-b/ unloads all of it and loads theirs. Nothing leaks between contexts. The .aliases file for each client can live in the project repo — versioned, auditable, shared with anyone else who works there.

Project aliases require a one-time am trust per repository — amoxide won't auto-load a file it hasn't seen before.

Eight years of development, 200-odd aliases. gcm might be git commit -m or git checkout master depending on which year you wrote it. Some refer to projects you no longer work on. Some are broken because the tool they wrapped was renamed. alias | grep git returns 40 lines and you still can't find the one you want.

The only way to discover an alias is to remember you made it. The only way to clean them up is to scroll through a file you haven't fully read in years. You know this needs doing. You keep putting it off.

amoxide turns this into a tractable afternoon. Move aliases into named profiles — work, personal, git, rust, ops — each a plain TOML section you can read, annotate, and understand. am ls shows exactly what's active right now. Nothing loads unless you, or a project directory, asked for it. The 200-alias pile becomes five profiles you actually trust.

Profiles can be activated together: am use git work layers both, with later profiles taking precedence on name conflicts.