# dotfiles.pro

> Dotfiles manager and machine provisioner for Ubuntu, macOS, and WSL, powered by Ansible. It manages the whole developer machine (packages, system configuration, repositories, and dotfiles) for one laptop or a fleet, from a single repository, via a local Ansible run with no agent or server.

Dotfiles Pro is the `dotfilespro.roles` Ansible collection. Your personal repository holds the variables and the list of roles to run; the collection holds the roles. An "apply" (one playbook run) declares the desired state, computes the target by merging defaults / `group_vars` / `host_vars` and rendering Jinja templates, then applies only the difference. It is idempotent: the first install and a routine update are the same code path, run locally (`connection: local`).

The full text of every page is at [https://dotfiles.pro/llms-full.txt](https://dotfiles.pro/llms-full.txt).

## Key facts

- Platforms: Ubuntu 24.04+, macOS (Homebrew, via the `macos` role), and WSL (with Windows-side integration via shims and WSLENV).
- Positioning vs chezmoi: chezmoi manages files in `$HOME`; Dotfiles Pro manages the whole machine. chezmoi's own design FAQ states that beyond a handful of home-directory files, tools like Ansible, Puppet, Chef, and Salt are better suited, so the difference is scope, not capability.
- No agent and no server: each machine configures itself with a local Ansible run.
- The `dotpro` role installs the `dotpro` CLI for the day-2 loop: `dotpro plan` previews an apply, `dotpro apply` runs it, `dotpro upgrade` refreshes the collection, and `doctor`, `vars`, `history`, and `versions` inspect the machine.
- Leaving is cheap: roles write ordinary files and install ordinary packages, so stopping the playbook leaves a fully working machine.

## Docs

- [About](https://dotfiles.pro/about): What Dotfiles Pro is, how to write its name (Dotfiles Pro, dotfiles.pro, and dotfilespro), who maintains it, and the license it ships under.
- [Architecture](https://dotfiles.pro/architecture): How Dotfiles Pro works: desired vs actual state, an apply that computes the target via merging and templating, the collection + personal-repo layout, and settings-not-files.
- [Changelog](https://dotfiles.pro/changelog): Notable changes to Dotfiles Pro. The project is unreleased, so one Unreleased section describes the first release: the install.sh bootstrap, the dotpro CLI, and every role.
- [Cheat sheet](https://dotfiles.pro/cheatsheet): Every shell alias and function Dotfiles Pro installs, grouped by role, in one overview.
- [Configuration](https://dotfiles.pro/configuration): Organize Dotfiles Pro variables by machine count (inline for one machine, an inventory for a few, group_vars/host_vars for many) and run different roles per machine from one repo.
- [Contributing](https://dotfiles.pro/contributing): How to contribute a role or fix to Dotfiles Pro: fork, branch, point your requirements.yml at the fork, test with tags, and open a merge request.
- [Dotfiles Pro](https://dotfiles.pro/readme): Dotfiles Pro sets up and maintains Ubuntu, macOS, and WSL machines with Ansible: a demo, why Ansible, the role list, a quick start, and where the documentation lives.
- [Examples](https://dotfiles.pro/examples/): Three ready-to-copy starters for Dotfiles Pro, One machine, Multiple machines (one inventory), and Many machines (group_vars/host_vars), with every file shown in full.
- [FAQ](https://dotfiles.pro/faq): Common questions about Dotfiles Pro: why Ansible over chezmoi, macOS and Windows support, secrets, shell startup quirks, and how to stop using it.
- [Getting started](https://dotfiles.pro/getting-started): Install Dotfiles Pro with one command, or wire it up by hand with Ansible, then apply your Ubuntu or WSL machine from your own dotfiles repo.
- [Highlights](https://dotfiles.pro/highlights): A tour of the everyday wins in Dotfiles Pro, the aliases, functions, and prompts that make a managed machine a pleasure to use, from git statuses across every repo to Lens on Windows authenticating through gcloud in WSL.
- [License](https://dotfiles.pro/license): Dotfiles Pro is released under the MIT License.
- [Links](https://dotfiles.pro/links/): Software Dotfiles Pro builds on and installs, related dotfiles managers and configuration tools, and learning resources.
- [Plugins](https://dotfiles.pro/plugins): Extend Dotfiles Pro with plugins, any Ansible collection installed alongside it. What a Dotfiles Pro plugin requires, how to get listed, and an index of compatible roles.

## Guides

- [Guides](https://dotfiles.pro/guide/): Practical, hands-on guides for managing your machine with Dotfiles Pro, from backing up your dotfiles to a reproducible apply.
- [Connect Lens on Windows to GKE through WSL](https://dotfiles.pro/guide/windows-lens-gke-through-wsl/): Make the Lens Kubernetes IDE on Windows authenticate to GKE through the gcloud and gke-gcloud-auth-plugin that live inside WSL, name-matched shims, exec.env account binding, and WSLENV, automated by the Dotfiles Pro wsl and googlecloud roles.
- [Hand off from an Ubuntu autoinstall to Dotfiles Pro](https://dotfiles.pro/guide/ubuntu-autoinstall/): Shrink your Subiquity autoinstall late-commands to a handoff: day-0 imaging installs the OS and base packages, Dotfiles Pro applies configuration, identity, repositories, and tooling on day 2, turning a pile of curl|bash installers into idempotent roles.
- [How to manage your dotfiles across machines](https://dotfiles.pro/guide/dotfiles-across-machines/): Back up, restore, and sync your dotfiles across machines, and the packages, system config, and repos around them. A practical guide from symlinks to a reproducible machine.
- [Keep $HOME clean with XDG Base Directories](https://dotfiles.pro/guide/xdg/): Use the XDG Base Directory Specification to stop apps cluttering $HOME. What the XDG_* variables are, how the unix role sets them to their defaults, how to move individual tools to ~/.config and friends, and why this lines up with the paths the roles already use.
- [Migrate from a hand-rolled bootstrap dotfiles repo](https://dotfiles.pro/guide/migrate-from-bootstrap/): Convert a Holman-style dotfiles repo (topic folders, *.symlink files, *.zsh autoloading, a bootstrap script, a bin directory) to Dotfiles Pro: map topics to roles, *.symlink files to the dotfiles role, *.zsh aliases and functions to vars, bin to ~/scripts, and retire the bootstrap glue.
- [Migrate from GNU Stow to Dotfiles Pro](https://dotfiles.pro/guide/migrate-from-stow/): Convert a GNU Stow dotfiles repo to Dotfiles Pro: map each stow package to a role or to the dotfiles role, retire stow, stow -R, and stow -D, sidestep the existing-target conflicts Stow chokes on, and gain packages, templating, per-host config, and secrets.
- [One repo for your Windows, Ubuntu, and macOS machines](https://dotfiles.pro/guide/windows-ubuntu-macos/): Structure one dotfiles repo for a cross-platform personal fleet (a Windows + WSL gaming PC, an Ubuntu laptop, and macOS machines) with a shared baseline plus per-machine roles and git identity.
- [Set up a company dotfiles collection](https://dotfiles.pro/guide/company-collection/): Pair your own company Ansible collection with the public Dotfiles Pro collection, three layers, no fork: shared roles upstream, company-specific roles and baseline defaults in company.roles, identity and taste in each personal repo.
- [Tune macOS with system defaults](https://dotfiles.pro/guide/macos-defaults/): A curated defaults write recipe book for the macos role's macos_defaults: keyboard repeat, Finder, screenshots, the Dock, save and print panels, and screensaver security, each applied idempotently as a setting you declare rather than a file you copy.

## Roles

- [Roles](https://dotfiles.pro/roles): The built-in Dotfiles Pro roles (ubuntu, macos, wsl, git, kubernetes, dotpro, starship, terraform, cloud CLIs, and more) grouped by purpose, with a tag system for partial runs.
- [Agents](https://dotfiles.pro/roles/agents): Generates the files coding agents read on every machine: a TOOLING.md inventory of installed CLIs, a PROJECTS.md map of your repositories, a synced Agent Skills catalog, and an optional shared ~/AGENTS.md for Claude Code, Codex, and others.
- [Ansible](https://dotfiles.pro/roles/ansible): Keeps Ansible itself managed: ansible-core with a matched Mitogen, installed with uv by default or apt on request, the per-host roles_extra list, and shell aliases for running an apply.
- [Atlassian](https://dotfiles.pro/roles/atlassian): Installs acli, the official Atlassian CLI, from Atlassian's apt repository or Homebrew tap, with Jira and Confluence aliases, bash completion, and per-shell account selection so terminals never collide.
- [AWS](https://dotfiles.pro/roles/aws): Installs the AWS CLI and AWSume for assume-role and profile switching, through apt on Ubuntu or Homebrew on macOS, and registers both so versions reports them.
- [Bash](https://dotfiles.pro/roles/bash): The bash shell role, which removes ~/.bash_profile so the ~/.profile framework applies, plus the shared task files other roles import to generate shell aliases, install scripts, and record tool versions.
- [Bitwarden](https://dotfiles.pro/roles/bitwarden): Installs the Bitwarden CLI (bw) as a native executable with no Node.js, points it at your Bitwarden server (EU by default), and adds zsh completion and shell aliases for common vault operations.
- [Claude](https://dotfiles.pro/roles/claude): Installs and updates Claude Code, merges your settings.json, and adds model aliases, Agent Skills, MCP servers, per-shell accounts, an optional CLAUDE.md that imports AGENTS.md, and a status line that follows the repository you edit.
- [Codex](https://dotfiles.pro/roles/codex): Installs and updates the OpenAI Codex CLI, merges codex_config into ~/.codex/config.toml without touching the state Codex keeps there, and adds Agent Skills, per-shell accounts, and an optional link to the shared ~/AGENTS.md.
- [DigitalOcean](https://dotfiles.pro/roles/digitalocean): Installs doctl, the DigitalOcean CLI, with shell aliases and functions, per-shell context selection so terminals never collide, and auto-renewing kubeconfigs instead of static tokens that expire after 7 days.
- [Docker](https://dotfiles.pro/roles/docker): Installs Docker and the docker compose plugin: docker.io through apt on Ubuntu and WSL, colima with the docker CLI through Homebrew on macOS, and opt-in Docker Desktop settings merged into its settings-store.json.
- [dotfiles](https://dotfiles.pro/roles/dotfiles): Places the raw dotfiles you list in dotfiles_list into $HOME on every apply: links, copies, or templates them, backs up the files it adopts, and prunes links you drop, the job stow or chezmoi apply would do.
- [dotpro](https://dotfiles.pro/roles/dotpro): The dotpro CLI, the apply engine and day-2 entry point: one command to install the collection, plan, and apply, plus doctor, vars, capture, and history, with sudo handling and several output modes.
- [Git](https://dotfiles.pro/roles/git): Installs Git and pre-commit, sets global Git config with per-directory conditional configs, clones your projects inventory, and adds 20+ shell aliases, git-statuses, and the worktree helper.
- [GitHub](https://dotfiles.pro/roles/github): Installs gh, the GitHub CLI, with shell aliases and functions, and keeps the account and host per shell, so terminals signed in to different GitHub accounts or hosts never collide.
- [GitLab](https://dotfiles.pro/roles/gitlab): Installs glab, the GitLab CLI, with shell aliases and functions, credential storage, and per-shell account selection across gitlab.com and self-hosted instances, so terminals on different accounts never collide.
- [Google Cloud](https://dotfiles.pro/roles/googlecloud): Installs the Google Cloud CLI (gcloud) with shell aliases and functions, keeps the account and project per shell so they stop reverting, and covers expired credentials and the missing gke-gcloud-auth-plugin.
- [Google Workspace](https://dotfiles.pro/roles/googleworkspace): Installs gws, the Google Workspace CLI, with aliases for triaging, searching, and reading your Gmail inbox, and per-shell account selection so each terminal reads one mailbox.
- [Grafana](https://dotfiles.pro/roles/grafana): Installs gcx, the Grafana CLI for Grafana Cloud and self-hosted Grafana 12 or later, with aliases for dashboards, datasources, and firing alert rules, and per-shell account selection.
- [Kubernetes](https://dotfiles.pro/roles/kubernetes): Installs kubectl, kubeseal, k9s, and Helm with the helm-diff plugin, plus 25+ shell aliases and functions, and keeps the kubeconfig and namespace per shell so a command never hits the wrong cluster.
- [macOS](https://dotfiles.pro/roles/macos): Base system setup for macOS with Homebrew: packages, system defaults, and the Dock, built on the same unix base role as Ubuntu so one personal repo covers Ubuntu, macOS, and WSL.
- [Nerd Fonts](https://dotfiles.pro/roles/nerdfonts): Installs Nerd Fonts system-wide (FiraCode by default) from the upstream release or Homebrew casks, and on WSL also registers them with Windows so Windows Terminal can select them.
- [OpenTofu](https://dotfiles.pro/roles/opentofu): Installs and updates OpenTofu (tofu) to the latest GitHub release with the official installer script, records its version, and adds shell aliases for common Tofu operations.
- [Projects](https://dotfiles.pro/roles/projects): Turns the machine's projects map into shell entry points: a jump alias per project, a projects list, and a project command that changes into the repository, titles the tab, and switches context.
- [Python](https://dotfiles.pro/roles/python): Installs Python 3 and pip through apt on Ubuntu or Homebrew on macOS, records their versions, and aliases python and pip to their Python 3 variants.
- [Sentry](https://dotfiles.pro/roles/sentry): Installs and updates sentry-cli, checksum-verified on Linux and through Homebrew on macOS, with aliases for projects, issues, and releases, and per-shell account selection so terminals never collide.
- [SSH](https://dotfiles.pro/roles/ssh): Installs Keychain so SSH keys stay loaded across shell sessions, and manages the host aliases in ~/.ssh/config from your vars.
- [Starship](https://dotfiles.pro/roles/starship): Installs and updates the Starship prompt and renders its config from vars, showing in each shell which Kubernetes context, cloud project, and GitHub, GitLab, or Sentry account a command will act on.
- [Terraform](https://dotfiles.pro/roles/terraform): Installs Terraform from HashiCorp's apt repository with a fingerprint-checked signing key, or its Homebrew tap on macOS, upgrades only on dotpro apply --upgrade, and adds aliases with workspace completion.
- [Ubuntu](https://dotfiles.pro/roles/ubuntu): Base system setup for Ubuntu and WSL: apt upgrades, system packages, locale, optional snaps, and sysctl tuning, on top of the unix base role that owns the ~/.profile.d/ shell framework.
- [Unix](https://dotfiles.pro/roles/unix): The OS-neutral base every platform role builds on: the ~/.profile.d/ shell framework, ~/scripts, version tracking in ~/.versions.d/, XDG base directories, and the generic aliases and functions.
- [Windows](https://dotfiles.pro/roles/windows): Manages Windows from inside WSL over the interop bridge: winget packages, user environment variables, registry settings, virtual desktops, and workspace launchers that open your apps on their desktops with one shortcut.
- [WSL](https://dotfiles.pro/roles/wsl): Configures WSL: /etc/wsl.conf, the Windows-side .wslconfig with memory-reclaim defaults, wslu utilities, BROWSER and WIN_HOME, Windows shims, and aliases for files, the clipboard, and Windows folders.
- [Zsh](https://dotfiles.pro/roles/zsh): The zsh shell role: the unix role includes it when the login shell is zsh (the default on macOS), and it initializes zsh completion through a ~/.profile.d/ fragment.

## Alternatives

- [Alternatives](https://dotfiles.pro/alternatives): Dotfiles Pro vs chezmoi, yadm, GNU Stow, Nix Home Manager, Salt, Puppet, MDM, devcontainers, and golden images, scored on each one's own terms, with migration in and out.
- [Bare git dotfiles alternative: Dotfiles Pro](https://dotfiles.pro/alternatives/bare-git/): The bare git repo trick versions your home directory with no extra tools; Dotfiles Pro manages the whole machine (packages, system config, templating, and repositories) with Ansible. Comparison and migration.
- [Chef alternative: Dotfiles Pro](https://dotfiles.pro/alternatives/chef/): Chef is Ruby-based configuration management for server fleets; Dotfiles Pro is agentless Ansible (YAML) focused on the developer machine, dotfiles, the personal layer, and WSL. Comparison.
- [chezmoi alternative: Dotfiles Pro](https://dotfiles.pro/alternatives/chezmoi/): chezmoi manages the files in your home directory; Dotfiles Pro manages the whole machine (packages, system config, repositories, and dotfiles) with Ansible. When to pick which, and how to migrate from chezmoi.
- [Devcontainers alternative: Dotfiles Pro](https://dotfiles.pro/alternatives/devcontainers/): Devcontainers standardize the per-project toolchain inside a container; Dotfiles Pro provisions the host machine that runs them. They compose rather than compete. Comparison.
- [Dotbot alternative: Dotfiles Pro](https://dotfiles.pro/alternatives/dotbot/): Dotbot bootstraps dotfiles with YAML-configured symlinks and shell commands; Dotfiles Pro is an idempotent Ansible run that manages the whole machine. Comparison and migration from Dotbot.
- [GNU Stow alternative: Dotfiles Pro](https://dotfiles.pro/alternatives/stow/): GNU Stow symlinks dotfiles from a repo into your home directory; Dotfiles Pro does that job too and manages the whole machine (packages, system config, and repositories) with Ansible. Comparison and migration from Stow.
- [Golden image alternative: Dotfiles Pro](https://dotfiles.pro/alternatives/golden-image/): A golden image bakes machine setup once at provisioning time; Dotfiles Pro applies continuously, repairs drift, and adopts onto existing machines with no reimaging. Comparison.
- [MDM alternative: Dotfiles Pro](https://dotfiles.pro/alternatives/mdm/): MDM and Landscape push and enforce machine policy from a central server; Dotfiles Pro is developer-owned, pull-based setup of the dev environment. They compose more than they compete. Comparison.
- [Nix Home Manager alternative: Dotfiles Pro](https://dotfiles.pro/alternatives/nix-home-manager/): Nix Home Manager and NixOS offer reproducible, declarative config with atomic rollback at a steep learning curve; Dotfiles Pro is low-learning-curve Ansible (YAML) you can adopt role by role. Comparison and migration.
- [Puppet alternative: Dotfiles Pro](https://dotfiles.pro/alternatives/puppet/): Puppet is declarative configuration management built for server fleets; Dotfiles Pro is agentless Ansible focused on the developer machine, dotfiles, the personal layer, and WSL. Comparison.
- [Salt alternative: Dotfiles Pro](https://dotfiles.pro/alternatives/salt/): Salt is general-purpose configuration management; Dotfiles Pro is Ansible focused on the developer machine (dotfiles, the personal layer, and WSL) adoptable role by role with no agent. Comparison.
- [yadm alternative: Dotfiles Pro](https://dotfiles.pro/alternatives/yadm/): yadm tracks your home directory with git plus templating and encryption; Dotfiles Pro manages the whole machine (packages, system config, and repositories alongside your dotfiles) with Ansible. Comparison and migration.

## Blog

- [Blog](https://dotfiles.pro/blog/): Engineering articles on dotfiles, machine provisioning, WSL, and team fleet setup, from the dotfiles.pro team.
- [Agent rules are config, not prose](https://dotfiles.pro/blog/agent-rules-are-config): The moment you have two machines or one teammate, a prose AGENTS.md forks, and forks drift. Treat agent instructions like the rest of your configuration instead: keyed data you override per rule, layered personal → project → company, versioned and applied like everything else. How the data model works, what the research says belongs in the rules, and the company tier nobody else has a mechanism for.
- [chezmoi for the files, Dotfiles Pro for the machine: one repo, a dotpro/ subdir](https://dotfiles.pro/blog/dotfiles-pro-and-chezmoi): Keep chezmoi managing the files in your home directory at the repo root, and add Dotfiles Pro in a dotpro/ subdirectory for packages, system config, and repos. The provisioner installs chezmoi and hands the files back to it.
- [Click a toast, land in the right terminal: reconstructing $WINDOWID on WSL](https://dotfiles.pro/blog/wsl-toast-click-focus-terminal): Windows Terminal won't tell a WSL shell which window hosts it, so notification clicks can't find their way back. Capture the window handle at the one moment it's provably knowable, stamp it on the toast as a protocol link, and a small validated handler does the rest.
- [Co-Authored-By is the wrong trailer for your coding agent](https://dotfiles.pro/blog/co-authored-by-vs-assisted-by): Claude Code signs its commits as your co-author by default. That's an authorship claim your forge parses and renders, and it's false. What the Linux kernel adopted instead, why the distinction matters for accountability, and how to switch your own machines with two settings and one rule.
- [Git worktrees: parallel checkouts for you and your coding agents](https://dotfiles.pro/blog/git-worktrees): Git worktrees give every branch its own directory, no stash-and-switch. What they are, where to put them, the gitignored-state trap that catches everyone, and one .worktrees/ convention that humans and Claude Code agents can share.
- [How to run multiple Slack instances on Windows, macOS, and Linux](https://dotfiles.pro/blog/multiple-slack-instances): Slack's workspace switcher shares one window, one notification stream, and one set of sign-ins. A --user-data-dir profile per client gives you genuinely separate Slack apps instead: launcher recipes for Windows, macOS, and Linux, plus the deep-link sign-in gotcha and its fix.
- [Keep your raw dotfiles, add a machine: Dotfiles Pro in the same repo](https://dotfiles.pro/blog/dotfiles-pro-and-a-raw-dotfiles-repo): Keep your plain dotfiles committed at the repo root, where a symlink or stow still works, and add machine provisioning to the same repo. The dotfiles role links the raw files selectively, so the two coexist with no subdirectory.
- [Lens on Windows, gcloud in WSL: GKE authentication across the boundary](https://dotfiles.pro/blog/lens-wsl-gke-auth): Lens on Windows has to run gke-gcloud-auth-plugin, which only exists inside WSL. Name-matched .cmd shims, a minimal PATH source, exec.env account binding in the kubeconfig, and WSLENV to cross the boundary, with the Ansible roles that keep it in place.
- [One hotkey per client: virtual desktops and workspaces on Windows](https://dotfiles.pro/blog/windows-virtual-desktops-workspaces): Windows virtual desktops give you the place but nothing to fill it. How to script them, switch to any desktop with one hotkey, launch apps onto a chosen desktop and monitor, and run one Slack per client, then the same setup as declarative config from WSL.
- [Provision the machine, spec the container: Dotfiles Pro and devcontainers](https://dotfiles.pro/blog/devcontainers-and-dotfiles): A devcontainer spec owns the project's toolchain, a provisioner owns the machine under it, and they meet at one place: the personal dotfiles hook. How to give one dotfiles repo two entry points, playbook.yaml for the machine and a plain POSIX install.sh for every container.
- [Route links by where you are: a virtual-desktop link router for Windows](https://dotfiles.pro/blog/windows-virtual-desktop-router): Link routers on Windows send a URL to a browser profile by rules you write ahead of time. This one routes by the virtual desktop you're on instead, handing http and slack:// links to the instance already open there, with no rulebook to maintain.
- [Run multiple isolated instances of any Electron app: the user-data-dir trick](https://dotfiles.pro/blog/electron-multiple-instances): Electron apps are single-instance because the lock lives inside the user data directory. One --user-data-dir per identity gives you two Slacks, two Discords, or two of anything Chromium-based, with separate sign-ins and notifications. The mechanism, and the gotchas it shares across apps.
- [Ship the prompt: put a paste-ready agent prompt in your docs](https://dotfiles.pro/blog/agent-prompts-in-documentation): Readers paste your install steps into a coding agent now. Write the prompt for them: one paste-ready block, authored by the person who knows what the artifact actually supports. The rules that keep it honest, and a VitePress ::: prompt container that keeps the copy button and degrades to clean markdown.
- [The agent-ready machine: generated context your agents can trust](https://dotfiles.pro/blog/agent-ready-machine): Coding agents start every session amnesiac, and the context files meant to fix that drift the moment they're written. The way out: stop writing context and start generating it, at provisioning time, from the same data that builds the machine. What's installed, where work lives, what happened recently: three small files, one apply, zero drift.
- [TOOLING.md: tell your coding agents what's in the toolbox](https://dotfiles.pro/blog/tooling-md-tell-agents-whats-installed): Coding agents discover CLI tools by trial and error, and a failed probe teaches them the wrong lesson for a whole session. The fix is a generated, verified tool inventory: install the right tools, scan for them on every apply, and hand agents one file that never lies. How the pattern works, what the ecosystem converged on, and how the agents role automates it.
- [Twenty laptops, one installer: closing the day-2 gap with a shared dotfiles collection](https://dotfiles.pro/blog/team-fleet-provisioning): A company autoinstall solves day 0 and then stops: installed is not configured. How an Ansible dotfiles collection closes the day-2 gap across a twenty-laptop fleet in three layers, upstream roles, a company collection, and each developer's own repo, without forking anything or taking a personal setup away.
- [Ubuntu and macOS on one team: a shared setup without a shared OS](https://dotfiles.pro/blog/ubuntu-macos-shared-standard): A mixed Ubuntu and macOS team can run one dotfiles standard, the same shell, aliases, and apply workflow on both, so collaboration stops depending on whose laptop it is.
- [What is Claude Code's auto-compact threshold, and can you change it?](https://dotfiles.pro/blog/claude-code-auto-compact-threshold): Claude Code's auto-compact threshold is not a fixed percentage: it's the context window minus a roughly fixed token reserve, about 83% on a 200K model and about 97% on a 1M one. Where the number comes from, why every blog cites a different one, what `/autocompact` and the two env vars actually move, how to turn it off, and how to see it coming in your status line.
- [What's the best Claude Code status line?](https://dotfiles.pro/blog/best-claude-code-statusline): What actually belongs on a Claude Code status line, in what order of importance, and how to build it with one simple shell script, no npm, no frameworks. Plus an honest look at ccstatusline, ccusage, and claude-powerline if you'd rather adopt than build.
- [What's the best dotfiles manager?](https://dotfiles.pro/blog/best-dotfiles-manager): Search best dotfiles manager and every thread says it depends, because dotfiles means two different jobs. An honest guide to GNU Stow, dotbot, bare git, yadm, chezmoi, and Nix home-manager by scope, and where a whole-machine tool like Dotfiles Pro fits instead.
- [Which account am I? Per-shell context isolation for cloud CLIs](https://dotfiles.pro/blog/per-shell-context-isolation): gcloud, kubectl, and doctl each keep 'which account am I' in one global file, so switching context in one terminal switches every terminal. Move that selection into per-shell environment variables and each window becomes its own isolated session, safe for parallel work and coding agents.
- [Which shell file runs when: the bash and zsh startup order](https://dotfiles.pro/blog/shell-startup-order): Why an alias works in one terminal but not another comes down to shell startup files. The bash and zsh loading order for login, non-login, interactive, and non-interactive shells, where the ~/.profile.d framework hooks in, and where its bash coverage stops.
- [Why a role beats a symlink: idempotent config the Ansible way](https://dotfiles.pro/blog/role-vs-symlink): Almost every dotfiles tool symlinks files from a repo into $HOME. Dotfiles Pro writes the settings instead, so software keeps its improved defaults, config stays partial and templated, and packages and dotfiles apply in one idempotent run. And it still symlinks when a verbatim file is what you want.

## Roadmap

- [Roadmap](https://dotfiles.pro/roadmap): Planned Dotfiles Pro work by area, from team provisioning and the dotpro CLI to releases, testing, and new roles, with a link to the design doc for each larger initiative.
- [atuin role: shell history sync (#56)](https://dotfiles.pro/roadmap/atuin): Plan for an opt-in atuin role: shell history in SQLite with a fuzzy Ctrl-R and end-to-end-encrypted sync across machines, opt-in because it rebinds Ctrl-R and the up arrow.
- [Devcontainers (and minimal / no-Ansible environments) (#21)](https://dotfiles.pro/roadmap/devcontainers): Plan for a file-only path that applies the shell framework subset in devcontainers and other boxes that can't run Ansible, without keeping a second dotfiles-lite repository.
- [dotpro progress callback: tag prediction (#6)](https://dotfiles.pro/roadmap/progress-callback): Remaining work on the dotpro progress output: its up-front role list comes from hand-rolled tag rules that are wrong at the edges, and should follow Ansible's real tag evaluation.
- [firefox: cross-platform browser management (#52)](https://dotfiles.pro/roadmap/firefox): Plan for a firefox role that manages settings, extensions, and one isolated profile per client on every platform, respecting the split between policies.json, user.js, and the files Firefox owns.
- [macOS container runtime (#27)](https://dotfiles.pro/roadmap/macos): Plan to make the macOS container runtime a per-host choice between colima, Docker Desktop, podman, and Apple's container, which needs docker-compatible aliases on top.
- [mitogen_parallel: single-host role parallelism (#11)](https://dotfiles.pro/roadmap/mitogen-parallel): Why an apply runs one host's roles serially, what a real single-host parallel strategy would take as a core-engine change, and the prefetch and merged apt install that already cut the wait.
- [Releases (#12)](https://dotfiles.pro/roadmap/releases): Plan for tagged releases so fleets upgrade deliberately: semantic versions, how to pin the collection, and publishing to Ansible Galaxy.
- [Settings capture: diff live config against defaults, suggest vars overrides (#8)](https://dotfiles.pro/roadmap/settings-capture): Remaining work on dotpro capture: subtract the keys your vars already manage from a live config, and add generate and baseline adapters for apps whose files hold full defaults.
- [SSH key handoff (#3)](https://dotfiles.pro/roadmap/ssh-key-handoff): Plan for an unattended deploy-key path so a non-interactive install.sh can clone a private personal repo on a keyless machine, and for which role owns that key afterward.
- [Team provisioning (#2)](https://dotfiles.pro/roadmap/team-provisioning): Plan for team provisioning: day-0 imaging hands off to day-2 applies, each person's repo layers over a small shared company collection, and the starter becomes a GitLab and GitHub template.
- [Testing (#22)](https://dotfiles.pro/roadmap/testing): Plan to prove roles apply and stay idempotent beyond the Ubuntu CI harness: macOS and Windows with WSL on GitHub Actions, which GitLab's shared runners can't host, and the roles left out.
- [Windows (#32)](https://dotfiles.pro/roadmap/windows): Plan for Windows work past the WSL interop bridge: WSL aliases that fire workspace launchers, scoop next to winget, and an SSH or WinRM transport for applying Windows settings headless.
- [windows: Terminal Overview (#39)](https://dotfiles.pro/roadmap/terminal-overview): Plan for an always-on-top Windows panel listing every terminal session waiting for you, across virtual desktops and Windows Terminal windows, built on the existing notification stream.