Your team wants one standard zsh setup across everyone's laptops and the CI images. How would you weigh oh-my-zsh against a plugin manager such as zinit or antidote against a hand-written ~/.zshrc, and what would you standardise regardless of which you pick?

## Separate three decisions that get conflated Teams argue about frameworks as if it were one choice. It is three. 1. **Who owns `~/.zshrc`?** A framework that installs itself by rewriting that file has taken authorship of your configuration; a plugin manager is a few lines inside a file you still write. 2. **When does third-party code load?** Eagerly at startup, deferred after the prompt appears, or pre-flattened into one file. 3. **What is genuinely shared?** The environment a script depends on is a completely different category from the prompt someone likes. ## oh-my-zsh A configuration framework with a large bundled library of plugins and themes. Its installer writes a new `~/.zshrc` from a template (preserving your old one alongside), and that template sets a theme name, lists plugins in an array, and sources the framework's entry point, which loads each named plugin from the bundle. What you get: a working, discoverable setup in one command, a big library, and a community answer to most questions. What it costs, as a *team standard* specifically: - **It owns the file.** Answering "why does my shell do that?" now means reading someone else's framework as well as your own configuration. - **Eager loading.** Everything listed loads at every shell start, used or not. - **Behaviour you did not choose.** Aliases and options arrive as a bundle. They are convenient right up to the moment somebody's muscle memory means something different on a production host than on their laptop. - **An upstream you rarely audit.** It self-updates; the code runs with your environment, your credentials, and your prompt. prezto occupies similar ground with a different structure — it supplies its own set of startup files and is configured through a dedicated file — and the same tradeoff analysis applies. ## Plugin managers zinit and antidote do less on purpose: fetch plugin repositories and make them loadable, leaving the configuration yours. The interesting difference is *load strategy*. zinit's turbo mode — the `wait` ice modifier — schedules a plugin to load shortly after the prompt is drawn, so startup cost stops scaling with plugin count. antidote takes the other route: it reads your plugin list and generates a single static file that `~/.zshrc` sources, replacing many small operations with one. Either beats eager sourcing, and both keep you as the author of the file. What you take on is dependency management: these are git repositories from arbitrary people, and "latest" is not a version. Pin refs. Review what you add. Understand that a shell plugin runs code before every prompt in an environment that usually holds cloud credentials. ## A hand-written ~/.zshrc Unfashionable and frequently correct. Most people use perhaps five things from a framework: a decent prompt, a good history configuration, completion, a handful of key bindings, one or two plugins. Written directly, that is under a hundred readable lines, starts in single-digit milliseconds, and has no upstream. For **CI images and shared servers this is close to mandatory.** A build agent does not want a themed prompt, and a shared host that drops responders into an unfamiliar interactive environment during an incident is a liability. ## What to standardise regardless The most important move is separating the contract from the taste. - **Version-control the dotfiles.** Whatever the team runs should be reviewable and diffable. - **Keep `~/.zshenv` minimal and non-interactive-safe** — quiet, quick, no assumption of a terminal. It is the file everything else runs through. - **Pin every third-party reference** to a commit or tag, and prefer vendoring or a generated static file over fetching at shell start. Nothing should hit the network to give someone a prompt. - **Decouple CI from interactive configuration.** Build steps run non-interactive shells that never read `~/.zshrc`; anything a pipeline needs belongs in the job definition or an image, not in a dotfile. - **Set a startup budget** and measure against it, so the configuration cannot rot into seconds. - **Standardise the contract, not the personality.** `PATH`, tool versions and behaviour scripts depend on should be identical for everyone. Prompt colours, aliases and key bindings should not be legislated — you will spend your credibility on the wrong thing, and people will work around you anyway. ## The prompt is its own decision Prompt frameworks are a separate axis from plugin loading: powerlevel10k with its configuration wizard and instant-prompt feature, or a cross-shell prompt tool, or twenty lines of `PROMPT` you wrote yourself. Choose it independently, and judge it on latency and on whether it makes dangerous context — which account, which host, which cluster — obvious at a glance. That last property is the only part of a prompt worth standardising for a team.