@xgent-ai/skills 0.1.0 → 0.3.0

package/skills/working-with-mise/references/dev-tools/tool-stubs-html.md

@@ -0,0 +1,416 @@
+Tool Stubs
+
+Tool Stubs [​](#tool-stubs)
+
+A tool stub is an executable file that records how to obtain and run one tool. Commit it to a repository so a command such as `./bin/py` selects the intended runtime and forwards its arguments. mise installs the tool on first execution; a normal project `mise install` does not discover and install arbitrary stub files.
+
+This feature is inspired by [dotslash](https://github.com/facebook/dotslash), which pioneered the concept of executable files with embedded configuration for portable tool execution.
+
+## Overview [​](#overview)
+
+A tool stub is an executable file that begins with a shebang line pointing to `mise tool-stub` and contains TOML configuration specifying which tool to execute and how to execute it. When the stub runs, mise installs the specified tool version (if needed) and executes it with the provided arguments.
+
+A stub requires `mise` on `PATH`, unless generated with the optional bootstrap wrapper. It can name a backend or provide HTTP download URLs. A backend stub uses that backend's version resolution; an HTTP stub records the artifact location directly.
+
+For a machine-wide catalogue of ordinary tools, prefer [`lazy = true` in `[tools]`](https://mise.jdx.dev/dev-tools/shims.html#lazy-tools). Standalone tool stub scripts remain useful when the executable file itself should carry a portable, self-contained tool definition.
+
+## Tool (non-http) Stubs [​](#tool-non-http-stubs)
+
+Create a `bin` directory, then save this file as `bin/py`:
+
+bin/py
+
+toml
+
+```
+#!/usr/bin/env -S mise tool-stub
+
+tool = "python"
+version = "3.14"
+bin = "python"
+```
+
+On Unix, make it executable and run it:
+
+sh
+
+```
+chmod +x ./bin/py
+./bin/py --version
+./bin/py -c 'import sys; print(sys.executable)'
+```
+
+The stub's name is `py`, but it runs the installed `python` executable. Arguments following the stub path are forwarded to Python. For an exact runtime, use a concrete version or [lock the stub](#locking-a-stub).
+
+Why use `env -S`?
+
+The `-S` flag tells `env` to split the command line on spaces, so multiple arguments can be passed to the interpreter. This is necessary because shebangs on Unix systems traditionally support only a single argument after the interpreter path. `env -S mise tool-stub` makes the shebang work by splitting it into `env` → `mise` → `tool-stub`.
+
+## Configuration Fields [​](#configuration-fields)
+
+A stub contains a tool declaration, not an entire `mise.toml`. Put fields at the top level; do not wrap them in `[tools]`. Backend-specific installation options are passed to the selected backend, while `tool`, `version`, `bin`, `os`, `install_env`, and embedded `lock` data control the stub itself.
+
+### Optional Fields [​](#optional-fields)
+
+- `tool` - Explicit tool name or backend specification (e.g., "python", "github:cli/cli"). If omitted, a top-level or platform-specific URL selects the HTTP backend; otherwise mise uses the stub filename as the tool name.
+- `version` - The version request (defaults to `latest`)
+- `bin` - The binary name to execute within the tool (defaults to the stub filename)
+- `os` - Operating systems on which the stub is available, optionally narrowed by architecture (for example, `["linux", "macos/arm64"]`)
+
+## HTTP Stubs [​](#http-stubs)
+
+A top-level URL applies to every platform on which the stub is run. Use it only for an artifact compatible with all of those machines. The URLs below are placeholders; use the generator to record real download metadata:
+
+toml
+
+```
+#!/usr/bin/env -S mise tool-stub
+url = "https://example.com/releases/1.0.0/tool.tar.gz"
+```
+
+For OS- or architecture-specific binaries, provide a platform table instead:
+
+toml
+
+```
+#!/usr/bin/env -S mise tool-stub
+[platforms.linux-x64]
+url = "https://example.com/releases/1.0.0/tool-linux-x64.tar.gz"
+
+[platforms.macos-arm64]
+url = "https://example.com/releases/1.0.0/tool-macos-arm64.tar.gz"
+```
+
+### Platform-Specific Binary Paths [​](#platform-specific-binary-paths)
+
+Set `bin` relative to the installed directory, after any archive root directory has been stripped. The generator accounts for that extraction layout. An explicit `--bin` must name the path that will remain after extraction.
+
+Use platform-specific `bin` fields when layouts or executable names differ:
+
+toml
+
+```
+#!/usr/bin/env -S mise tool-stub
+# Global bin field used when platforms have the same structure
+bin = "bin/tool"
+
+[platforms.linux-x64]
+url = "https://example.com/tool-linux.tar.gz"
+# Uses global bin field: "bin/tool"
+
+[platforms.windows-x64]
+url = "https://example.com/tool-windows.zip"
+bin = "tool.exe"  # Platform-specific binary for Windows
+```
+
+The tool stub generator detects when platforms have different binary paths and generates platform-specific `bin` fields when needed, or a single global `bin` field when all platforms share the same binary structure.
+
+TIP
+
+Tool stubs default to the HTTP backend when download URLs are present and no `tool` field selects another backend. See the [HTTP backend documentation](https://mise.jdx.dev/dev-tools/backends/http.html) for full details on configuring HTTP-based tools.
+
+## Generating Tool Stubs (http) [​](#generating-tool-stubs-http)
+
+While you can create tool stubs manually, mise provides a [`mise generate tool-stub`](https://mise.jdx.dev/cli/generate/tool-stub.html) command that generates stubs for HTTP-based tools.
+
+Incremental Building
+
+When using platform-specific URLs, the tool stub generator appends new platforms to existing stub files rather than overwriting them. This lets you build cross-platform tool stubs incrementally by running the command multiple times with different platforms.
+
+### Basic Generation [​](#basic-generation)
+
+Generate a tool stub for a tool distributed via HTTP:
+
+bash
+
+```
+mise generate tool-stub ./bin/gh --url "https://github.com/cli/cli/releases/download/v2.96.0/gh_2.96.0_linux_amd64.tar.gz"
+```
+
+This will:
+
+- Download the archive and record a checksum of those bytes
+- Extract it to auto-detect the binary path
+- Generate an executable stub with download and execution metadata
+
+A generated checksum detects later changes to the artifact. It does not by itself authenticate the publisher of the initial download. Review the URL and obtain it from a source you trust before committing the stub.
+
+### Platform-Specific Generation [​](#platform-specific-generation)
+
+For tools with different URLs per platform, you can generate all platforms at once:
+
+bash
+
+```
+mise generate tool-stub ./bin/rg \
+  --platform-url linux-x64:https://github.com/BurntSushi/ripgrep/releases/download/14.0.3/ripgrep-14.0.3-x86_64-unknown-linux-musl.tar.gz \
+  --platform-url macos-arm64:https://github.com/BurntSushi/ripgrep/releases/download/14.0.3/ripgrep-14.0.3-aarch64-apple-darwin.tar.gz
+```
+
+**Auto-Platform Detection**: If the URL contains platform information, you can omit the platform prefix and let mise auto-detect it:
+
+bash
+
+```
+# Auto-detect platform from URL (detects as 'macos-arm64')
+mise generate tool-stub ./bin/node \
+  --platform-url https://nodejs.org/dist/v22.17.1/node-v22.17.1-darwin-arm64.tar.gz
+
+# Auto-detect platform from URL (detects as 'linux-x64')
+mise generate tool-stub ./bin/node \
+  --platform-url https://nodejs.org/dist/v22.17.1/node-v22.17.1-linux-x64.tar.gz
+```
+
+Or build them incrementally by adding platforms one at a time:
+
+bash
+
+```
+# Start with Linux support (explicit platform)
+mise generate tool-stub ./bin/rg \
+  --platform-url linux-x64:https://github.com/BurntSushi/ripgrep/releases/download/14.0.3/ripgrep-14.0.3-x86_64-unknown-linux-musl.tar.gz
+
+# Later, add macOS support using auto-detection (appends to existing file)
+mise generate tool-stub ./bin/rg \
+  --platform-url https://github.com/BurntSushi/ripgrep/releases/download/14.0.3/ripgrep-14.0.3-aarch64-apple-darwin.tar.gz
+
+# Add Windows support using auto-detection (appends to existing file)
+mise generate tool-stub ./bin/rg \
+  --platform-url https://github.com/BurntSushi/ripgrep/releases/download/14.0.3/ripgrep-14.0.3-x86_64-pc-windows-msvc.zip
+```
+
+The generator merges new platforms into the existing `[platforms]` table. Re-specifying a platform updates that entry, so inspect the diff before committing. Use explicit platform prefixes when a filename is ambiguous.
+
+### Generation Options [​](#generation-options)
+
+- `--version VERSION` - Specify the tool version (defaults to "latest")
+- `--bin PATH` - Override the auto-detected binary path
+- `--platform-url PLATFORM:URL` - Add a platform-specific URL (can be repeated)
+- `--platform-url URL` - Add a platform-specific URL, auto-detecting the platform from the URL filename
+- `--platform-bin PLATFORM:PATH` - Set a platform-specific binary path
+- `--checksum-algorithm ALGORITHM` - Generate `blake3` (default) or `sha256` checksums
+- `--skip-download` - Generate without checksums or binary detection; review the binary path and run `--fetch` before relying on integrity checks
+- `--lock` - Resolve and embed lockfile data (pinned version + platform URLs/checksums) into an existing stub
+- `--fetch` - Fetch missing checksums and sizes for an existing stub file
+
+`--checksum-algorithm` cannot be combined with `--lock` or `--skip-download`, because those modes do not calculate checksums.
+
+For consumers such as Bazel that require SHA256 checksums, select that algorithm when generating the stub:
+
+bash
+
+```
+mise generate tool-stub ./bin/tool \
+  --url "https://example.com/tool.tar.gz" \
+  --checksum-algorithm sha256
+```
+
+The selected algorithm also applies to missing checksums populated by `--fetch`. Existing checksums are preserved.
+
+### Supported Archive Formats [​](#supported-archive-formats)
+
+The generator automatically detects and extracts various archive formats:
+
+- `.tar.gz` / `.tgz` (gzip compressed tarballs)
+- `.tar.xz` / `.txz` (xz compressed tarballs)
+- `.tar.bz2` / `.tbz2` (bzip2 compressed tarballs)
+- `.tar.zst` / `.tzst` (zstd compressed tarballs)
+- `.zip` (zip archives)
+- `.7z` (7-zip archives)
+
+### Generated Stub Example [​](#generated-stub-example)
+
+Inspect the generated file rather than entering a checksum or size by hand:
+
+sh
+
+```
+cat ./bin/gh
+```
+
+The file contains the URL, executable path, checksum, and size discovered from the archive. `version` may be omitted when it has the default value `latest`. For an HTTP stub, that label does not make a versioned URL track newer releases; update the URL and regenerate its metadata when upgrading.
+
+The output filename becomes the tool name. Set `--bin` if auto-detection selects the wrong executable, especially when an archive contains several commands.
+
+## Examples [​](#examples)
+
+### Basic Node.js Stub [​](#basic-node-js-stub)
+
+toml
+
+```
+#!/usr/bin/env -S mise tool-stub
+# Node.js tool stub
+
+tool = "node"
+version = "24"
+bin = "node"
+```
+
+### Python with Custom Binary Name [​](#python-with-custom-binary-name)
+
+toml
+
+```
+#!/usr/bin/env -S mise tool-stub
+# Python tool accessible as 'py'
+
+tool = "python"
+version = "3.14"
+bin = "python"
+```
+
+### GitHub Release Backend [​](#github-release-backend)
+
+toml
+
+```
+#!/usr/bin/env -S mise tool-stub
+# GitHub CLI tool
+
+tool = "github:cli/cli"
+version = "latest"
+bin = "gh"
+```
+
+### Locked Tool Stub [​](#locked-tool-stub)
+
+Lock a backend stub to record a concrete version and the platform download metadata its backend can provide. The generator writes this under `[lock]`; the top-level `tool` still selects the backend, and `version` becomes the resolved version.
+
+Stored URLs can avoid release discovery on later installs. They do not remove private-download authentication or every backend's verification and policy requests. Review the generated platforms and checksums; a backend that cannot provide a URL cannot supply the same download shortcut.
+
+#### Locking a Stub [​](#locking-a-stub)
+
+bash
+
+```
+# Create a stub with a fuzzy version
+mise generate tool-stub ./bin/node --version 24
+
+# Lock it to pin the exact version and add platform URLs/checksums
+mise generate tool-stub ./bin/node --lock
+```
+
+By default, this resolves the version and fetches URLs for all common platforms (linux-x64, linux-x64-musl, linux-arm64, linux-arm64-musl, macos-x64, macos-arm64, and windows-x64). If `lockfile_platforms` is configured, it uses those platforms plus the current platform instead. The generated metadata is written into a `[lock]` section in the stub.
+
+#### Bumping a Locked Version [​](#bumping-a-locked-version)
+
+To bump the version of a locked stub, pass `--version` along with `--lock`:
+
+bash
+
+```
+# Select Node.js 26 and regenerate the locked metadata
+mise generate tool-stub ./bin/node --lock --version 26
+```
+
+### HTTP Backend with Platform Support [​](#http-backend-with-platform-support)
+
+toml
+
+```
+#!/usr/bin/env -S mise tool-stub
+# Custom HTTP tool with platform-specific downloads
+
+version = "1.0.0"
+
+[platforms.linux-x64]
+url = "https://releases.example.com/v{{version}}/tool-linux-x64.tar.gz"
+
+[platforms.macos-arm64]
+url = "https://releases.example.com/v{{version}}/tool-macos-arm64.tar.gz"
+```
+
+## Usage [​](#usage)
+
+### Direct Execution [​](#direct-execution)
+
+Make the stub executable and run it directly:
+
+bash
+
+```
+chmod +x ./bin/my-tool
+./bin/my-tool --version
+```
+
+#### On Windows [​](#on-windows)
+
+Windows cannot execute a shebang script, so `mise generate tool-stub` writes a `.cmd` launcher beside the stub. Run the stub by name and Windows picks it up through `PATHEXT`:
+
+powershell
+
+```
+.\bin\my-tool.cmd --version
+```
+
+The launcher is generated whenever the stub could run on Windows. An explicit `os` selector must include Windows, and any platform tables must include a `[platforms.windows-*]` entry. A stub that declares neither restriction also gets a launcher. A stub limited to Linux and macOS does not get one, and neither does a stub whose own name already ends in `.cmd`, `.bat` or `.exe`. The launcher is written on every platform, not just Windows, so a stub generated on Linux and committed to a repository still works for someone who clones it on Windows.
+
+If a stub later stops shipping for Windows, regenerating it removes the launcher, so it cannot keep running against platforms the stub no longer declares. Only a launcher mise generated is removed — one you wrote yourself is left alone.
+
+The extension-less stub is kept as well: Git Bash and Cygwin run it through the shebang, the same way [shims](https://mise.jdx.dev/dev-tools/shims.html) place both an extension-less script and a native launcher on Windows.
+
+### Via mise Command [​](#via-mise-command)
+
+Run the stub through the [`mise tool-stub`](https://mise.jdx.dev/cli/tool-stub.html) command—useful for debugging when something isn't working:
+
+bash
+
+```
+mise tool-stub ./bin/my-tool --version
+```
+
+## Caching [​](#caching)
+
+Tool stubs cache lookups to reduce the overhead mise adds when running them:
+
+- Binary paths are cached based on the stub file path and modification time
+- The cache is invalidated automatically when the stub file changes
+- Missing binaries trigger cache cleanup automatically
+
+Each invocation still passes through mise. For repeated calls inside a script, consider preparing the environment once with `mise exec` and calling the tool directly from that script.
+
+## Pruning [​](#pruning)
+
+Executing a stub tracks it in `~/.local/state/mise/tracked-stubs`, the same way config files are tracked when they are used. [`mise prune`](https://mise.jdx.dev/cli/prune.html) treats tool versions referenced by a tracked stub as needed and will not delete them, just like versions required by a tracked config file.
+
+A stub must have been executed at least once on the machine for its tool to be protected. If the stub file is later deleted, its tool versions become prunable again (unless something else needs them).
+
+## Alternative: Creating Simple Stubs with `mise x` [​](#alternative-creating-simple-stubs-with-mise-x)
+
+For basic use cases, you can create simple stubs with the [`mise x`](https://mise.jdx.dev/cli/exec.html) command instead of writing TOML configuration:
+
+bash
+
+```
+# Create bin directory
+mkdir -p ./bin
+
+# Create a simple Node.js stub
+cat > ./bin/node << 'EOF'
+#!/usr/bin/env bash
+exec mise x node@24 -- node "$@"
+EOF
+chmod +x ./bin/node
+
+# Create a Python stub with specific version
+cat > ./bin/python << 'EOF'
+#!/usr/bin/env bash
+exec mise x python@3.14 -- python "$@"
+EOF
+chmod +x ./bin/python
+```
+
+The command after `--` is essential: `mise x node@24` selects the runtime, and `node "$@"` names the executable and preserves the caller's arguments. These wrappers require Bash and mise and do not embed artifact metadata. Use the TOML stub format when you need platform mappings or embedded lock data.
+
+[Edit this page](https://github.com/jdx/mise/edit/main/docs/dev-tools/tool-stubs.md)
+
+Last updated:
+
+Pager
+
+[Previous pageTool Aliases](https://mise.jdx.dev/dev-tools/aliases.html)
+
+[Next pageRegistry](https://mise.jdx.dev/registry.html)
+
+MIT License·Copyright © 2026· [![](https://github.com/jdx.png?size=96)jdx.dev](https://jdx.dev)

package/skills/working-with-mise/references/guides/getting-started.md

@@ -0,0 +1,268 @@
+Getting started
+
+Getting started [​](#getting-started)
+
+By the end of this guide, you'll have a project with a managed tool, an environment variable, and a task you can run. Shell activation is optional: the first examples work without changing your shell configuration.
+
+Already installed mise for an existing project? Review its `mise.toml`, then run `mise install` from the project directory. Use `mise tasks ls` to see its tasks.
+
+## 1. Install `mise` CLI [​](#installing-mise-cli)
+
+See [installing mise](https://mise.jdx.dev/installing-mise.html) for other ways to install mise (Homebrew, MacPorts, apt, Nix, and more).
+
+Linux/macOSWindowsDebian/Ubuntu (apt)Fedora 41+, RHEL/CentOS Stream 9+ (dnf)Snap
+
+shell
+
+```
+curl https://mise.run | sh
+```
+
+The installer places the mise executable in `~/.local/bin`.
+
+Verify the installation:
+
+shell
+
+```
+~/.local/bin/mise --version
+# mise 2026.x.x
+```
+
+- `~/.local/bin` does not need to be in `PATH`. mise will automatically add its own directory to `PATH` when [activated](#activate-mise).
+
+To customize where mise stores downloaded tools and other data, see [directories](https://mise.jdx.dev/directories.html).
+
+## 2. Run your first tool [​](#mise-exec-run)
+
+Use [`mise exec`](https://mise.jdx.dev/cli/exec.html) to run a command with a specific tool version:
+
+sh
+
+```
+mise exec node@24 -- node --version
+```
+
+By default, mise downloads the tool if needed, then runs the command after `--`. This does not add Node.js to your project configuration or change your current shell's environment. The output starts with `v24.`; the patch version may vary.
+
+TIP
+
+If `mise` isn't on `PATH` yet, use `~/.local/bin/mise` instead on macOS or Linux. Activation in [step 4](#activate-mise) adds mise to your shell's `PATH`.
+
+## 3. Set up a project [​](#set-up-a-project)
+
+For a fresh example, create a new directory. If you are using an existing project, start in its root and skip the first two commands:
+
+sh
+
+```
+mkdir mise-example
+cd mise-example
+mise use node@24
+```
+
+[`mise use`](https://mise.jdx.dev/cli/use.html) installs the tool and writes its version request to `mise.toml`. Unlike `mise install`, it also changes your configuration.
+
+### Set an environment variable [​](#environment-variables)
+
+Edit the generated `mise.toml` to contain:
+
+mise.toml
+
+toml
+
+```
+[tools]
+node = "24"
+
+[env]
+NODE_ENV = "development"
+```
+
+Run a command with both the configured tool and environment:
+
+sh
+
+```
+mise exec -- node -p process.env.NODE_ENV
+# development
+```
+
+You can also [load variables from a `.env` file](https://mise.jdx.dev/environments/#env-directives).
+
+### Run a task [​](#run-a-task)
+
+Add this section to the same `mise.toml`:
+
+mise.toml
+
+toml
+
+```
+[tasks.hello]
+description = "Print the project's Node.js version and environment"
+run = '''node -e "console.log(process.version, process.env.NODE_ENV)"'''
+```
+
+sh
+
+```
+mise run hello
+```
+
+The output includes a Node.js version starting with `v24.` and `development`. Tasks get the project's tools and environment automatically. By default, `mise run` installs missing configured tools before running the task.
+
+Commit `mise.toml` so teammates and CI can use the same configuration. The version request `"24"` selects a release in the Node.js 24 series; it is not an exact pin. See [lockfiles](https://mise.jdx.dev/dev-tools/mise-lock.html) to share resolved versions across machines.
+
+### Project configuration or global defaults? [​](#project-configuration-or-global-defaults)
+
+| Command | What it does |
+| --- | --- |
+| `mise use node@24` | Installs Node.js and saves the version request in the project config. Run it from your project directory. |
+| `mise use --global node@24` | Installs Node.js and saves a personal default in the global config. |
+| `mise install` | Installs tools already declared in your configuration. |
+| `mise exec -- node --version` | Runs one command with the project's tools and environment. |
+| `mise run hello` | Runs a named task with the project's tools and environment. |
+
+Project configuration can override global defaults. Use `mise config ls` to see which files are active and `mise ls --current` to inspect the selected tools.
+
+### Trusting config files [​](#trust)
+
+Review configuration from other people before running it: tasks, hooks, and some environment directives can execute code. Use `mise trust` to explicitly trust a config you've reviewed.
+
+In normal mode outside CI, commands that execute project behavior, including `mise install`, `mise exec`, and `mise run`, automatically trust the active config. With [paranoid mode](https://mise.jdx.dev/paranoid.html), non-global configs require explicit trust. See [`mise trust`](https://mise.jdx.dev/cli/trust.html) for details.
+
+### Confirm what is active [​](#confirm-what-is-active)
+
+sh
+
+```
+mise config ls
+mise ls --current
+mise tasks ls
+mise exec -- node --version
+```
+
+Use these from the project directory to check configuration discovery, tool selection, task discovery, and command execution before adding shell activation.
+
+## 4. Activate `mise` optional [​](#activate-mise)
+
+`mise exec` works great for one-off commands, but for interactive shells you'll probably want to activate mise so tools and environment variables are loaded automatically.
+
+There are two approaches:
+
+- [`mise activate`](https://mise.jdx.dev/cli/activate.html) — updates your `PATH` and environment every time your prompt runs. Recommended for interactive shells.
+- [Shims](https://mise.jdx.dev/dev-tools/shims.html) — command entry points that select tool versions. Useful for editors and other programs that do not load your shell config. [Shims don't support all features of `mise activate`](https://mise.jdx.dev/dev-tools/shims.html#shims-vs-path).
+
+You can skip both and use `mise exec` or `mise run` to load the project environment explicitly, including in CI and scripts.
+
+Choose the instructions for your installation method and shell. Add the activation line once; repeating an append command can create duplicate hooks. For custom zsh or fish configuration locations, use your shell's actual config path instead of the default shown below.
+
+mise.run installerBrewWindowsOther package managers
+
+bashzshfish
+
+sh
+
+```
+echo 'eval "$(~/.local/bin/mise activate bash)"' >> ~/.bashrc
+```
+
+sh
+
+```
+echo 'eval "$(~/.local/bin/mise activate zsh)"' >> ~/.zshrc
+```
+
+sh
+
+```
+mkdir -p ~/.config/fish
+echo '~/.local/bin/mise activate fish | source' >> ~/.config/fish/config.fish
+```
+
+Restart your shell session after modifying your rc file. Run [`mise dr|doctor`](https://mise.jdx.dev/cli/doctor.html) to verify everything is set up correctly.
+
+With mise activated, tools are available directly on `PATH`:
+
+sh
+
+```
+mise use --global node@24
+node -v
+# v24.x.x
+```
+
+When you ran `mise use --global node@24`, mise updated your global config:
+
+\~/.config/mise/config.toml
+
+toml
+
+```
+[tools]
+node = "24"
+```
+
+## 5. Find more tools [​](#tool-backends)
+
+Use the [registry](https://mise.jdx.dev/registry.html) to find tool names such as `node`, `python`, `jq`, and `ripgrep`. Most of the time, the name is all you need:
+
+sh
+
+```
+mise use ripgrep
+mise exec -- rg --version
+```
+
+A **backend** tells mise where to get a tool and how to install it. You can choose one explicitly, including for tools without a registry shorthand:
+
+sh
+
+```
+mise exec github:BurntSushi/ripgrep -- rg --version
+```
+
+Some backends require another runtime or package manager. Check the [backend guide](https://mise.jdx.dev/dev-tools/backends/) before using a new ecosystem.
+
+## 6. Next steps [​](#next-steps)
+
+- **Keep working in a project:** follow the [walkthrough](https://mise.jdx.dev/walkthrough.html) for configuration overrides, upgrades, and daily commands.
+- **Write build and test commands:** see [tasks](https://mise.jdx.dev/tasks/).
+- **Use mise outside a terminal:** set up your [editor](https://mise.jdx.dev/ide-integration.html) or [CI pipeline](https://mise.jdx.dev/continuous-integration.html).
+- **Set up a machine:** use [bootstrap](https://mise.jdx.dev/bootstrap.html) for declared system packages, dotfiles, and services.
+
+### Set up autocompletion [​](#autocompletion)
+
+Enable [shell completions](https://mise.jdx.dev/installing-mise.html#autocompletion) to complete tools, versions, and task names.
+
+### If something doesn't work [​](#if-something-doesn-t-work)
+
+Run `mise doctor` to check your setup. If a tool works through `mise exec` but not as a plain command, check [shell activation](#activate-mise) and restart your shell. See [troubleshooting](https://mise.jdx.dev/troubleshooting.html) for other common problems.
+
+#### GitHub API rate limiting [​](#github-api-rate-limiting)
+
+If an error reports GitHub API rate limiting, configure a [GitHub token](https://mise.jdx.dev/dev-tools/github-tokens.html).
+
+### Shell Feature Compatibility [​](#shell-feature-compatibility)
+
+Not all shells support every mise feature:
+
+| Feature | Bash | Zsh | Fish | Nushell | Elvish | Xonsh | PowerShell |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| `mise activate` | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
+| `mise shell` | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
+| Shell aliases (`[shell_alias]`) | Yes | Yes | Yes | No | No | No | No |
+| `chpwd` hook | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
+
+PowerShell's directory-change hook requires PowerShell 7 or newer. Other activation behavior remains available on supported older PowerShell versions.
+
+[Edit this page](https://github.com/jdx/mise/edit/main/docs/getting-started.md)
+
+Last updated:
+
+Pager
+
+[Next pageDemo](https://mise.jdx.dev/demo.html)
+
+MIT License·Copyright © 2026· [![](https://github.com/jdx.png?size=96)jdx.dev](https://jdx.dev)