mise-toolkit

Detect the user's shell and add `mise activate` to their shell rc file

Install AI CLIs (claude, codex, aichat, gemini) via mise with redacted API key env vars

Walk the user through getting and setting API keys for claude, codex, and gemini — securely, never writing plaintext

Build the jdx/mise Rust binary via the mise task

Generate devcontainer.json + Codespaces prebuild config for zero-cold-start onboarding

Combined full-vertical setup — C++ toolchain plus AI CLIs in one mise.toml (for dev-tool projects)

One-shot bootstrap of a modern C++ toolchain via mise (cmake + ninja + ccache + clang-tools)

Survey a C++ project and propose a mise.toml with cmake, ninja, ccache, fast linker, and clang-tools

Generate a devcontainer.json wired for mise with VSCode extensions, postCreateCommand, and trust env

Generate a multi-stage Dockerfile with mise pre-installed (builder + runtime, BuildKit cache mount, non-root user)

Run mise doctor and analyze the output for problems

Explain what mise is in 60 seconds, with concrete examples for a zero-knowledge user

Survey the current project and propose a mise.toml using modern best practices

Install mise on the user's host system (cross-platform installer with shell activation)

Wire JetBrains IDEs to mise — install intellij-mise plugin or apply the asdf-symlink workaround

Run lint with autofix and stage the result

Detect the source version manager and migrate the project to mise

Print the mise daily-use cheat sheet

Ask 3-4 questions and recommend a personalized mise adoption path

Refresh the local mise llms.txt knowledge cache from mise.jdx.dev

Regenerate jdx/mise docs, completions, and JSON schema

Safely reset mise state — uninstall tools but preserve configs and lockfiles

Update cargo insta snapshots for jdx/mise

Run jdx/mise e2e tests via the mise task (never invoke test files directly)

Diagnose and fix mise trust issues (the

Run a comprehensive mise health check and explain each finding

Wire VSCode to mise — install the mise-vscode extension, configure automation profile, or fall back to shims-on-PATH

Use when setting up AI CLIs (Claude, Codex, Gemini, aichat) via mise — "install claude code via mise", "set up AI CLIs for this project", "add an ai-status task", "configure OpenAI and Anthropic keys", or "/mise-ai-init". Picks which CLIs to install, writes the [env] + [redactions] blocks with correct redaction, sets up the ai-status task, and hands off to /mise-ai-keys for the actual key-setting step. Never writes plaintext secrets to any file.

Use when implementing, modifying, or reviewing tool backends in the jdx/mise Rust codebase under src/backend/** or core plugins in src/plugins/core/**. Triggers on "add a backend to mise", "fix the cargo backend", "implement install_version_impl", "review my backend PR", or any work touching the Backend trait. Knows the trait contract, the cross-backend conventions, and the registry mapping rules.

Use when a mise.toml is broken or behaving unexpectedly. Triggers on "mise isn't working", "mise doctor shows errors", "why is my tool version wrong", "mise trust issues", "config not loading", "mise.toml not detected", or after the user runs mise dr and gets warnings. Diagnoses configuration, hierarchy, trust, and activation problems.

Use when setting up C++ tooling for a project via mise — "set up cmake", "add ninja and ccache", "I need a fast linker", "wire up clang-format and clang-tidy", "what should my C++ mise.toml look like", or "/mise-cpp-init". Surveys the project for C++ artifacts, picks cmake / ninja / ccache / linker / package manager / clang-tools versions, and proposes a complete mise.toml with env var wiring for the golden trio.

Use when deciding how to deploy mise — "should I use Docker", "set this up in a container", "devcontainer for this project", "deploy mise to production", "mise in CI", or "what's the best way to run mise here". Picks the right model (host / Docker / devcontainer / Codespaces / CI runner / dotfiles) based on project shape, team constraints, and IDE requirements, then coordinates with mise-integration-architect for the mise.toml side and points at the right commands for the container/IDE side.

Use when writing or modifying bash end-to-end tests under e2e/** in the jdx/mise repo. Triggers on "write an e2e test", "add a test for the install command", "test the new backend", or any work touching e2e/. Knows the assertion helpers in e2e/assert.sh, the harness conventions, and the rule against running e2e files directly.

Use when integrating mise into a project for the first time, or when the user says "set up mise", "add mise to this project", "what should my mise.toml look like", or "/mise-init". Surveys the project for existing version-manager artifacts, env files, scripts, and CI, then proposes a complete mise.toml using modern best practices and the preferred backend per tool.

Use when migrating a project from another version manager to mise. Triggers on "migrate from nvm", "migrate from pyenv", "migrate from asdf", "replace direnv with mise", "switch from volta to mise", "/mise-migrate", and similar. Knows the file formats, pinning conventions, and gotchas of nvm, fnm, volta, n, pyenv, poetry, uv, rbenv, chruby, asdf, jenv, sdkman, tfenv, and direnv.

Use when converting npm scripts, Makefile targets, Justfile recipes, or shell scripts into mise tasks. Triggers on "add a mise task", "convert npm scripts to mise", "replace Makefile with mise tasks", "write a task", or when the user wants tasks with dependencies, file watching, or sources/outputs caching.

A 60-second pitch for mise aimed at zero-knowledge users — what it is, what it replaces, why it's better, what it isn't, and the smallest possible mise.toml. Use whenever the user asks "what is mise", "is mise worth it", "should I try mise", or seems unsure whether to adopt it.

The full mise [env] system — _.file (dotenv/json/yaml), _.path, _.source, _.<plugin>, tools=true lazy eval, required vars with help text, redactions, config_root resolution, and array-of-tables for multiple directives. Use whenever the user works on env vars in mise.toml, hits a "var not loaded" issue, or needs secrets/dynamic env handling.

The CRITICAL distinction between system packages (apt/brew/dnf — libssl, libpq, build-essential) and dev tools (mise — node, python, cmake, ripgrep). The

Cross-cutting overview of how to wire mise into every major IDE — VSCode, JetBrains, Neovim, Xcode, Zed, Sublime Text. The "if you're not sure where to start" entry point that points to per-IDE skills for depth. Use when a user says "how do I make my IDE see mise".

Every way to install mise itself — curl/sh, brew, apt, dnf, pacman, snap, nix, winget, scoop, choco, MacPorts, source, Docker. Plus uninstall, upgrade, and the install paths each method uses. Use when installing mise on a new machine, recommending an install method, or troubleshooting "command not found" after install.

Wiring JetBrains IDEs (IntelliJ, PyCharm, GoLand, RubyMine, WebStorm, Android Studio) to mise using the 134130/intellij-mise plugin, plus the ~/.asdf symlink workaround for plugins that don't natively support mise yet. Covers per-language SDK selection and Gradle/Maven integration.

Go modules deep dive — workspace mode, replace directives, private modules with GOPRIVATE, vendoring vs the module cache, and when to use `go install` vs mise's go: backend. Use when working with Go module layouts or troubleshooting dependency resolution.

Go via mise — go.mod toolchain directive vs .go-version vs mise.toml precedence, GOPATH / GOBIN layout with mise, and the go: backend for installing CLIs built from source. Use when setting up Go for a project.

Node.js via mise — .nvmrc / .node-version / package.json engines auto-detection, LTS vs current, the corepack + packageManager field, and when to use the npm: backend for global CLIs. Use when setting up Node for a project or explaining how mise handles Node versions.

Node package managers — npm vs pnpm vs yarn vs bun. Why corepack + the packageManager field is the right pinning answer, when to use mise's npm: backend for global CLIs vs project-local deps, and the monorepo story. Use when picking a Node package manager or explaining corepack.

Python via mise — .python-version auto-detection, idiomatic_version_file_enable_tools, how mise compiles Python under the hood (python-build), the pre-built binaries route via MISE_PYTHON_COMPILE=0, and when to pin patch versions. Use when setting up Python for a project or troubleshooting Python installs.

Python package managers — uv vs poetry vs pipx vs pip. The rule is "mise pins python, uv/poetry manages project venv, pipx manages global CLIs". Covers the uv-first workflow (the current recommended default) and why mixing tools is the

Ruby gem management — bundler as the project-level dep manager, the vendor/bundle pattern, rubocop / standard / solargraph installation choices, and why mise's gem: backend is limited compared to aqua for Ruby CLIs that exist. Use when managing gems for a project.

Ruby via mise — .ruby-version / Gemfile ruby directive auto-detection, why system Ruby is always wrong, bundler as the gem manager on top of mise-pinned Ruby, and the OpenSSL / readline build-dep story. Use when setting up Ruby for a project.

The cargo ecosystem — cargo vs mise's cargo: backend for installing CLIs (prefer aqua over cargo build-from-source for ripgrep/fd/bat/etc.), sccache for compile caching, cargo-nextest as a test runner, cargo workspaces, and when to pin rustc exact vs channel. Use when working with cargo deps or CLIs.

Rust via mise — rust-toolchain.toml auto-detection, the mise-over-rustup architecture, channel selection (stable/beta/nightly), components (clippy, rustfmt, rust-src, rust-analyzer), and targets. Use when setting up Rust for a project or explaining how mise + rustup interact.

The mise.lock workflow — generating, committing, environment-specific lockfiles, strict locked mode for hermetic CI, provenance verification, and the install_before supply-chain delay. Use when setting up reproducible builds, hardening CI, debugging "why is the wrong version installing", or recommending lockfile practices.

Migrating a project from asdf to mise — preserving .tool-versions, plugin compatibility, the global config gotcha, asdf-go vs asdf-bash differences, and the recommended deprecation steps. Use when the user mentions "migrate from asdf", "switch from asdf", or has a .tool-versions file they want to convert.

The direnv vs mise [env] overlap story — when mise's built-in [env] is enough to replace direnv entirely, when to keep direnv running alongside mise via the use mise integration, and how to translate common .envrc patterns to mise.toml. Use when a user is currently using direnv and wants to consolidate or coexist with mise.

Migrating from nvm to mise — reading .nvmrc, translating `nvm use` shell hooks, tearing down ~/.nvm cleanly, and handling the common bashrc/zshrc entries. Use when a user is currently using nvm and wants to adopt mise without losing their pinned Node versions.

Migrating from pyenv to mise — reading .python-version, handling pyenv-virtualenv markers, translating pyenv-installed versions, handling the compile-from-source situation, and tearing down ~/.pyenv cleanly. Use when a user is currently using pyenv and wants to adopt mise.

Migrating from rbenv to mise — reading .ruby-version, handling rbenv-gemset, preserving installed rubies, and tearing down ~/.rbenv cleanly. Use when a user is currently using rbenv and wants to adopt mise for Ruby version management.

Migrating from tfenv to mise — reading .terraform-version, translating tfenv-installed versions, handling the terraform vs tofu fork decision, and tearing down ~/.tfenv cleanly. Use when a user is currently using tfenv for Terraform version management.

Wiring Neovim to mise — using vim.env.PATH to prepend the mise shims directory, handling LSP servers installed via mise vs mason.nvim, and the mise neovim cookbook pattern. Use when setting up Neovim for a project that uses mise-managed tools.

High-level orientation to mise (mise-en-place) — what it is, what it replaces, when to recommend it, and the three things it does (dev tools, env vars, tasks). Use whenever the user mentions mise for the first time in a conversation, asks "what is mise", "should I use mise", "mise vs asdf/nvm/pyenv/direnv/make", or wants a quick refresher on the mental model.

When to use `mise activate` vs `mise activate --shims` vs `mise exec` vs `mise env` vs `mise en` vs `mise run` — what each does, what each loads, and what each can't. Use when the user is choosing between activation methods, or when something works in one mode but not another (especially "[env] vars not set in IDE").

Activation snippets for every shell mise supports — bash, zsh, fish, nushell, elvish, xonsh, PowerShell — plus the dual-mode pattern for IDE compatibility, and the difference between login/interactive rc files. Use when adding `mise activate` to a shell rc, debugging "mise not loading", or supporting an unusual shell.

Writing mise tasks in TOML — fields, dependencies, parallelism, sources/outputs caching, env scoping, hooks via tasks, output modes, and the difference between TOML tasks and file tasks. Use when creating, editing, debugging, or converting scripts to mise tasks.

The complete structure of a mise.toml file — every top-level section, what merges across the config hierarchy, and which file mise writes to when you run `mise use` or `mise set`. Use when designing a mise.toml from scratch, reviewing one, debugging hierarchy issues, or answering "what goes in mise.toml".

Every way to specify a tool version in mise — exact, fuzzy, latest, lts, prefix, ref, sub, path — plus tool options like os, depends, postinstall, install_env. Use when writing or editing the [tools] section of mise.toml, picking a version syntax, or troubleshooting "wrong version installed".

Diagnostic flowchart for common mise problems — tool not found, wrong version, env vars missing, slow shell, trust issues, install failures, GitHub rate limits, IDE not seeing tools, mise.toml not loaded. Use as the first stop when something is broken; routes to more specific skills/agents based on the symptom.

The mise trust system, paranoid mode, idiomatic version files (which are OPT-IN), supply-chain settings (`install_before`, provenance verification), and how to handle trust issues in CI / monorepos. Use when the user hits trust prompts, asks "should I trust this", configures CI, sets up a monorepo, or wants to harden mise security.

Head-to-head comparisons of mise against asdf, nvm, fnm, pyenv, rbenv, jenv, sdkman, tfenv, volta, direnv, brew, apt, and Docker — when each beats mise and when mise wins. Use when the user is deciding whether to switch, comparing tools, or asking "why mise instead of X".

Wiring VSCode to mise — the hverlin.mise-vscode extension, the terminal.integrated.automationProfile.osx quirk, dual-mode setup (mise activate in .zshrc plus shims in .zprofile), and why VSCode tasks / debuggers need special handling beyond just setting PATH.

The modern C++ toolchain at a glance — cmake, ninja, ccache, fast linkers (mold/lld), clang-tools, and package managers (conan/vcpkg) — with a decision framework for when to pin each via mise vs system apt/brew. Use when setting up C++ in a project for the first time.

The five deployment models for mise — native host (Linux/Mac), Docker base image, devcontainer / Codespaces, CI runner, and dotfiles-as-code — with the trade-offs and the file you need to write for each. Use when deciding "where should mise live" or "host vs container".

The full devcontainer.json schema for projects using mise — features, postCreateCommand, mounts, customizations.vscode, containerEnv, and the trust + activation patterns that the stock `mise generate devcontainer` output misses. Use when writing or reviewing a .devcontainer/devcontainer.json.

Picking the right Docker base image for mise — debian:slim vs ubuntu vs alpine (with the musl caveat) vs nvidia/cuda vs mcr.microsoft.com/devcontainers/base. Covers glibc vs musl, tool compatibility, and image-size trade-offs.

The `mise generate bootstrap -l -w` pattern for pinning mise in Dockerfiles and CI without `curl | sh`. Commit `./bin/mise` so builds are reproducible and network-free for the mise install step.

The builder → runtime multi-stage split for mise-based Dockerfiles — what to copy across stages, when mise itself belongs in the runtime stage, and how to keep the runtime image small without losing reproducibility.

The canonical patterns for running mise inside Docker — multi-stage builder/runtime split, BuildKit cache mounts for ~/.local/share/mise/installs, when mise belongs in the runtime stage, and the non-root user pattern. Use when writing a Dockerfile that installs mise or copies mise-managed tools into a container.

Adding a tool to the mise registry by creating registry/<name>.toml. This is the 90% case for "add support for X to mise" — usually a one-file PR pointing at an existing backend (aqua > github/gitlab > pipx/npm/cargo/go/dotnet). Use when contributing a new tool short-name to jdx/mise.

Orientation for contributing to the jdx/mise Rust codebase — repo layout, build/test/lint commands, conventional-commit scopes, the hk pre-commit setup, and the rule that e2e tests must run via `mise run test:e2e` (never directly). Use whenever the user is working in the jdx/mise repo itself.

Conventions for writing bash e2e tests in jdx/mise under e2e/** — assertion helpers, layout, the rule against direct invocation, the no-cleanup harness, and the no-chmod rule. Use whenever contributing tests to e2e/.

clang-format, clang-tidy, clangd, and include-what-you-use — install via mise (aqua backends where possible), wire into CI, and the one-version-per-project rule. Use when setting up code quality tooling for a C++ project.

The golden trio for C++ builds — cmake + ninja + ccache. Covers ccache config (CCACHE_DIR, size, compression), ninja parallelism, CMake preset integration with mise, and the env var pattern that wires them together. Use when configuring a C++ build.

mold vs lld vs system ld — when to pick each, how to wire them via mise, and the link-time speedup for large C++ projects. Covers Linux-only mold, cross-platform lld, and Apple's ld-prime. Use when link times dominate your build loop.

Conan 2.x vs vcpkg — how to pick between them, how to integrate each with mise via [tasks], and why conan should be installed via pipx (not mise's cargo/go backends). Use when the project needs third-party C++ libraries.

Security-focused guide for AI CLI API keys — threat model, storage options (shell rc / keychain / 1Password / doppler), rotation cadence, detection of accidental plaintext leaks, and why `mise set` is never the right answer for secrets. Use when setting up or rotating keys.

The four main AI CLIs compared — Claude Code, OpenAI Codex, Google Gemini, and aichat — with provider lock-in, model-agnostic fallback strategy, and why installing all four via mise is a lightweight dev-environment win. Use when picking AI CLIs for a project.

The canonical mise.toml pattern for AI CLIs — [tools] block with aqua backends, [env] with required + redact directives, [redactions] patterns, and the ai-status task. Covers production alternatives (keychain, 1Password CLI, doppler) for environments beyond shell rc files. Use when wiring AI CLIs into a project.

All 15 mise backends (aqua, asdf, cargo, conda, dotnet, forgejo, gem, github, gitlab, go, http, npm, pipx, s3, spm, ubi, vfox), their use cases, security profile, and the official preference order for picking one. Use when deciding how to install a tool, debugging "no backend found", or recommending a backend for a new tool.

Wiring mise into GitHub Actions using jdx/mise-action — version pinning, automatic redaction, lockfile-based caching, the bootstrap script alternative, and patterns for matrix builds. Also covers GitLab CI, generic docker, and Xcode Cloud at a glance. Use when setting up CI for a mise project, debugging "mise not found in CI", or hardening CI against rate limits.

Comprehensive mise CLI reference grouped by task — tools, tasks, env, exec, config, lockfile, generators, shell aliases, settings. Use whenever the user needs the exact command for an action, or asks "what's the command for X". For the daily 20-command subset, use /mise-quickref instead.

GitHub Codespaces specifics for mise — prebuilds, repo secrets, image caching, free-tier vs paid considerations, and what goes in onCreateCommand vs postCreateCommand. Use when setting up Codespaces for a project with mise.

Step-by-step playbook for adding a new tool backend to the jdx/mise Rust codebase. Use when contributing to jdx/mise and implementing a new install source under src/backend/. Walks the Backend trait, registration, tests, and the conventional commit. NOT for adding a new tool to an existing backend (that's a registry entry — see mise-contrib-add-registry).

6 hooks across 3 events