@xgent-ai/skills 0.1.0 → 0.3.0

package/skills/working-with-mise/references/dev-tools/backends/spm-html.md

@@ -0,0 +1,201 @@
+SPM Backend
+
+SPM Backend [​](#spm-backend)
+
+You may install executables managed by [Swift Package Manager](https://www.swift.org/documentation/package-manager) directly from GitHub or GitLab releases.
+
+The code for this backend is in the mise repository at [`./src/backend/spm.rs`](https://github.com/jdx/mise/blob/main/src/backend/spm.rs).
+
+When a release publishes a SwiftPM artifact bundle (`*.artifactbundle.zip`), mise uses the prebuilt executable from the bundle when it matches the current Swift target triple. If no matching bundle is available, mise falls back to building the package from source unless artifact bundles are explicitly required.
+
+## Dependencies [​](#dependencies)
+
+This backend needs Swift even for artifact bundles, because mise asks Swift for the target triple. Source builds also need Git and the package's build dependencies. You can install it [manually](https://www.swift.org/install) or [with mise](https://mise.jdx.dev/lang/swift.html).
+
+NOTE
+
+If you have Xcode installed and selected in your system via `xcode-select`, Swift is already available through the toolchain embedded in the Xcode installation.
+
+## Usage [​](#usage)
+
+With the required Swift toolchain available, install Tuist in the current project on macOS:
+
+sh
+
+```
+mise use spm:tuist/tuist
+mise exec -- tuist --help
+```
+
+This writes the following to `mise.toml`. Add `-g` for global configuration. Check the package's required Swift/Xcode version before building from source.
+
+toml
+
+```
+[tools]
+"spm:tuist/tuist" = "latest"
+```
+
+If the release provides only a SwiftPM artifact bundle, mise can install the bundle directly:
+
+sh
+
+```
+mise use spm:giginet/swift-testing-revolutionary@0.4.0
+mise exec -- swift-testing-revolutionary --help
+```
+
+The project configuration is:
+
+toml
+
+```
+[tools]
+"spm:giginet/swift-testing-revolutionary" = "0.4.0"
+```
+
+### Supported Syntax [​](#supported-syntax)
+
+| Description | Usage |
+| --- | --- |
+| GitHub shorthand for latest release version | `spm:tuist/tuist` |
+| GitHub shorthand for specific release version | `spm:tuist/tuist@4.15.0` |
+| GitHub url for latest release version | `spm:https://github.com/tuist/tuist.git` |
+| GitHub url for specific release version | `spm:https://github.com/tuist/tuist.git@4.15.0` |
+| GitHub shorthand for a specific commit | `spm:owner/repo@rev:<commit>` |
+| GitHub url for a specific commit | `spm:https://github.com/owner/repo.git@rev:<commit>` |
+
+Other syntax may work but is unsupported and untested.
+
+Commit selectors (`rev:<commit>` and the compatible `ref:<commit>` form) always build the package from source. Use a full commit SHA for a reproducible installation. Artifact bundles are release assets and cannot be combined with a commit selector.
+
+## Tool Options [​](#tool-options)
+
+The following [tool-options](https://mise.jdx.dev/dev-tools/#tool-options) are available for the backend — these go in `[tools]` in `mise.toml`.
+
+### `install_env` [​](#install-env)
+
+Set environment variables for Swift Package Manager commands such as `swift package dump-package`, `swift -print-target-info`, and `swift build`. For artifact bundle installs, this only applies to `swift -print-target-info`; the download, extract, and symlink steps are handled by mise directly. On macOS, for a system Swift toolchain, select the Xcode developer directory with:
+
+toml
+
+```
+[tools]
+"spm:tuist/tuist" = { version = "latest", install_env = { DEVELOPER_DIR = "/Applications/Xcode.app/Contents/Developer" } }
+```
+
+### `provider` [​](#provider)
+
+Set the provider type to use for fetching assets and release information. Either `github` or `gitlab` (the default is `github`). If you use shorthand notation with `api_url` for a self-hosted repository, set `provider` explicitly, since the type usually cannot be derived from the URL.
+
+toml
+
+```
+[tools]
+"spm:patricklorran/ios-settings" = { version = "latest", provider = "gitlab" }
+```
+
+### `api_url` [​](#api-url)
+
+Set the URL for the provider's API. This is useful when using a self-hosted instance.
+
+toml
+
+```
+[tools]
+"spm:acme/my-tool" = { version = "latest", provider = "gitlab", api_url = "https://gitlab.acme.com/api/v4" }
+```
+
+### `artifactbundle` [​](#artifactbundle)
+
+Control whether SwiftPM artifact bundles are used. When unset, mise tries a matching `*.artifactbundle.zip` release asset first and falls back to building from source if no matching bundle is available.
+
+Set `artifactbundle = true` to require an artifact bundle for a tool. If no bundle matches the current Swift target triple, installation fails instead of falling back to a source build.
+
+Set `artifactbundle = false` to skip artifact bundles and always build from source.
+
+toml
+
+```
+[tools]
+"spm:giginet/swift-testing-revolutionary" = { version = "0.4.0", artifactbundle = true }
+"spm:tuist/tuist" = { version = "latest", artifactbundle = false }
+```
+
+### `artifactbundle_asset` [​](#artifactbundle-asset)
+
+Select a specific artifact bundle release asset. This is required when a release contains multiple `*.artifactbundle.zip` assets.
+
+toml
+
+```
+[tools]
+"spm:giginet/swift-testing-revolutionary" = { version = "0.4.0", artifactbundle_asset = "swift-testing-revolutionary.artifactbundle.zip" }
+```
+
+### `filter_bins` [​](#filter-bins)
+
+Restrict which executable products are installed from the package or artifact bundle. When unset, every executable product declared in `Package.swift` is built and symlinked into `bin/`, or every matching executable artifact from an artifact bundle is symlinked into `bin/`.
+
+Useful when a package ships helper executables (e.g. test harnesses) that you don't want on your `PATH`. For source builds, filtering happens before `swift build`, so unwanted products are never built.
+
+Accepts a TOML array or a comma-separated string. If any listed name does not match an executable product in the package, installation fails with a clear error.
+
+toml
+
+```
+[tools]
+"spm:swiftlang/swiftly" = { version = "latest", filter_bins = ["swiftly"] }
+# Equivalent string form:
+# "spm:swiftlang/swiftly" = { version = "latest", filter_bins = "swiftly" }
+```
+
+### `install_command` [​](#install-command)
+
+Run an explicit command from the checked-out package directory instead of discovering executable products and running `swift build --product`. The command uses mise's default inline shell and inherits [`install_env`](https://mise.jdx.dev/dev-tools/backends/spm.html#install-env) plus the `PATH` for the Swift dependency. `PREFIX` and `MISE_TOOL_INSTALL_PATH` are both set to the tool's installation directory.
+
+This option only applies to source installs and cannot be combined with `filter_bins`. mise never automatically runs a package's Makefile or other installation scripts; the command must be configured explicitly.
+
+Useful for packages whose executable is not the only artifact that has to be installed — for example a package that also ships a dynamic library or Swift modules that its own `make install` target places next to the binary:
+
+toml
+
+```
+[tools]
+"spm:owner/repo" = { version = "1.2.3", artifactbundle = false, install_command = "make install PREFIX=\"$MISE_TOOL_INSTALL_PATH\"" }
+```
+
+Some install scripts exit successfully even when the underlying `swift build` failed, so mise verifies that the command installed at least one executable into `bin/` and fails the install otherwise.
+
+## Settings [​](#settings)
+
+### `spm.artifactbundle_only` [​](#spm-artifactbundle-only)
+
+Set `spm.artifactbundle_only = true` to require SwiftPM artifact bundles for all `spm:` installs. This mirrors `cargo.binstall_only`: mise fails if no matching artifact bundle is available instead of compiling from source.
+
+toml
+
+```
+[settings]
+spm.artifactbundle_only = true
+```
+
+This can also be set with `MISE_SPM_ARTIFACTBUNDLE_ONLY=1`.
+
+## Troubleshooting [​](#troubleshooting)
+
+- **No matching artifact bundle:** check the Swift target triple. Allow a source build only if the package supports your host and its build prerequisites are installed.
+- **Unexpected compilation:** set `artifactbundle = true` when a missing prebuilt bundle should fail instead of triggering a source build.
+- **No executable products:** confirm the package publishes a CLI, check `filter_bins`, or use an explicit `install_command` when the project has a custom installation process.
+
+[Edit this page](https://github.com/jdx/mise/edit/main/docs/dev-tools/backends/spm.md)
+
+Last updated:
+
+Pager
+
+[Previous pagepkgx](https://mise.jdx.dev/dev-tools/backends/pkgx.html)
+
+[Next pageubi](https://mise.jdx.dev/dev-tools/backends/ubi.html)
+
+MIT License·Copyright © 2026· [![](https://github.com/jdx.png?size=96)jdx.dev](https://jdx.dev)

package/skills/working-with-mise/references/dev-tools/backends/ubi-html.md

@@ -0,0 +1,232 @@
+Ubi Backend
+
+Ubi Backend deprecated [​](#ubi-backend)
+
+WARNING
+
+The ubi backend is **deprecated**. Use the [GitHub backend](https://mise.jdx.dev/dev-tools/backends/github.html) instead.
+
+The GitHub backend offers several advantages over ubi, including provenance verification, download progress reports, and fewer dependencies. To migrate, replace `ubi:owner/repo` with `github:owner/repo` in your configuration files. The [`matching`](https://mise.jdx.dev/dev-tools/backends/github.html#matching) and [`matching_regex`](https://mise.jdx.dev/dev-tools/backends/github.html#matching-regex) options carry over. One behavioral difference is worth noting: ubi applies the substring `matching` only as a tiebreaker among assets that already match your OS/arch, and skips it when a single asset matches the platform. The GitHub backend applies `matching` as a pre-filter before autodetection, so for multi-binary releases you get the binary your filter names, or a clear error naming the filter if it isn't published for your platform.
+
+One migration gotcha: ubi folds `matching` into the install path, so you can install several binaries from one repo via separate `matching` values on the same `ubi:owner/repo` string. The GitHub backend keeps the install path keyed by tool name + version only, so two `github:owner/repo` entries with different `matching` values resolve to the **same** directory and the second overwrites the first. If you rely on that ubi pattern, give each binary its own [`tool_alias`](https://mise.jdx.dev/dev-tools/backends/github.html#multiple-assets-from-the-same-release) on GitHub so each gets its own install directory.
+
+This page documents existing ubi configurations. For new installations, use the [GitHub](https://mise.jdx.dev/dev-tools/backends/github.html), [GitLab](https://mise.jdx.dev/dev-tools/backends/gitlab.html), or [HTTP](https://mise.jdx.dev/dev-tools/backends/http.html) backend as appropriate.
+
+## Usage [​](#usage)
+
+Migrate one tool at a time. For a simple release install, change:
+
+toml
+
+```
+[tools]
+"ubi:BurntSushi/ripgrep" = "14.1.1"
+```
+
+To:
+
+toml
+
+```
+[tools]
+"github:BurntSushi/ripgrep" = "14.1.1"
+```
+
+Then run `mise install` and `mise exec -- rg --version`. Check custom options against the destination backend: for example, `exe` and `extract_all` are ubi options and should not be copied blindly. Regenerate and review any lockfile. Keep the old installation until the replacement works.
+
+For multiple binaries, follow the alias migration described above. A direct `ubi:https://...` download belongs in an [HTTP tool entry](https://mise.jdx.dev/dev-tools/backends/http.html#usage).
+
+## Tool Options [​](#tool-options)
+
+The following [tool-options](https://mise.jdx.dev/dev-tools/#tool-options) are available for the `ubi` backend—these go in `[tools]` in `mise.toml`.
+
+### `exe` [​](#exe)
+
+The `exe` option allows you to specify the executable name in the archive. This is useful when the archive contains multiple executables.
+
+If you get an error like `could not find any files named cli in the downloaded zip file`, you can use the `exe` option to specify the executable name:
+
+toml
+
+```
+[tools]
+"ubi:cli/cli" = { version = "latest", exe = "gh" } # github's cli
+```
+
+### `rename_exe` [​](#rename-exe)
+
+The `rename_exe` option allows you to specify the name of the executable once it has been extracted.
+
+Use the `rename_exe` option to specify the target executable name:
+
+toml
+
+```
+[tools]
+"ubi:cli/cli" = { version = "latest", exe = "gh", rename_exe = "github" } # github's cli
+```
+
+### `matching` [​](#matching)
+
+Set a string to match against the release filename when there are multiple files for your OS/arch, e.g. "gnu", "musl", or "msvc". This is only used when more than one release filename matches your OS/arch; if only one release asset matches, the option is ignored.
+
+toml
+
+```
+[tools]
+"ubi:BurntSushi/ripgrep" = { version = "latest", matching = "musl" }
+```
+
+### `matching_regex` [​](#matching-regex)
+
+Set a regular expression to match against release filenames before matching against OS/arch. If the pattern yields a single match, that file is selected. If nothing matches, ubi reports an error.
+
+toml
+
+```
+[tools]
+"ubi:shader-slang/slang" = { version = "latest", matching_regex = "\\d+\\.tar" }
+```
+
+### `provider` [​](#provider)
+
+Set the provider used to fetch assets and release information: either `github` or `gitlab` (default `github`). Set `provider` explicitly when you use `api_url`, since the type probably cannot be derived correctly from the URL.
+
+toml
+
+```
+[tools]
+"ubi:gitlab-org/cli" = { version = "latest", exe = "glab", provider = "gitlab" }
+```
+
+### `api_url` [​](#api-url)
+
+Set the URL for the provider's API. This is useful when using a self-hosted instance.
+
+toml
+
+```
+[tools]
+"ubi:acme/my-tool" = {
+  version = "latest",
+  provider = "gitlab",
+  api_url = "https://gitlab.acme.com/api/v4",
+}
+```
+
+### `extract_all` [​](#extract-all)
+
+Set to `true` to extract all files in the tarball instead of only the binary. Not compatible with `exe` or `rename_exe`.
+
+toml
+
+```
+[tools]
+"ubi:helix-editor/helix" = { version = "latest", extract_all = true }
+```
+
+### `bin_path` [​](#bin-path)
+
+The directory in the tarball containing the binaries. This is useful when the binary is not at the root of the tarball, and it only makes sense when `extract_all` is set to `true`.
+
+toml
+
+```
+[tools]
+"ubi:owner/repo" = {
+  version = "latest",
+  extract_all = true,
+  bin_path = "target/release", # match the archive's actual layout
+}
+```
+
+**Binary path lookup order:**
+
+1. If `bin_path` is specified, use that directory
+2. If `extract_all` is set to `true`, use the install path root
+3. If `bin_path` is not set, look for a `bin/` directory in the install path
+4. If no `bin/` directory exists, use the root of the extracted directory
+
+### `tag_regex` [​](#tag-regex)
+
+Set a regex to filter out tags that don't match it. This is useful when a vendor publishes releases for unrelated CLIs in the same repo. For example, `cargo-bins/cargo-binstall` has many releases for CLIs other than `cargo-binstall`; this option filters those releases out.
+
+toml
+
+```
+[tools]
+"ubi:cargo-bins/cargo-binstall" = { version = "latest", tag_regex = '^\d+\.' }
+```
+
+## Self-hosted GitHub/GitLab [​](#self-hosted-github-gitlab)
+
+If you are using a self-hosted GitHub/GitLab instance, you can set the `provider` and `api_url` tool options. Additionally, you can set the `MISE_GITHUB_ENTERPRISE_TOKEN` or `MISE_GITLAB_ENTERPRISE_TOKEN` environment variable to authenticate with the API.
+
+## Supported Ubi Syntax [​](#supported-ubi-syntax)
+
+- **GitHub shorthand for latest release version:** `ubi:goreleaser/goreleaser`
+- **GitHub shorthand for specific release version:** `ubi:goreleaser/goreleaser@1.25.1`
+- **URL syntax:** `ubi:https://github.com/goreleaser/goreleaser/releases/download/v1.16.2/goreleaser_Darwin_arm64.tar.gz`
+
+## Troubleshooting ubi [​](#troubleshooting-ubi)
+
+### `ubi` resolver can't find os/arch [​](#ubi-resolver-can-t-find-os-arch)
+
+Sometimes vendors name their releases in ways ubi can't figure out, possibly only for a specific OS/arch combination. For example, in [this ticket](https://github.com/houseabsolute/ubi/issues/79) a vendor used "mac" instead of the more common "macos" or "darwin" tags.
+
+For an existing ubi install, compare with a separately installed ubi CLI if you need to isolate its resolver. Run this in an empty scratch directory:
+
+sh
+
+```
+ubi -p jdx/mise
+./bin/mise --version
+```
+
+### `ubi` picks the wrong tarball [​](#ubi-picks-the-wrong-tarball)
+
+A GitHub release may have many tarballs, some of which don't contain the CLI you want. Use the `matching` field to specify a string to match against the release filenames.
+
+sh
+
+```
+mise use 'ubi:tamasfe/taplo[matching=full]'
+# or with ubi directly
+ubi -p tamasfe/taplo -m full
+```
+
+### `ubi` can't find the binary in the tarball [​](#ubi-can-t-find-the-binary-in-the-tarball)
+
+ubi assumes the repo name is the same as the binary name, but that is often not the case. For example, BurntSushi/ripgrep provides a binary named `rg`, not `ripgrep`. In this case, specify the binary name with the `exe` field:
+
+sh
+
+```
+mise use 'ubi:BurntSushi/ripgrep[exe=rg]'
+# or with ubi directly
+ubi -p BurntSushi/ripgrep -e rg
+```
+
+### `ubi` uses weird versions [​](#ubi-uses-weird-versions)
+
+This issue is with mise, not ubi. mise needs to list the available versions of a tool so that "latest" points to the actual latest release of the CLI. Sometimes vendors publish GitHub releases for unrelated things. For example, `cargo-bins/cargo-binstall` is the repo for cargo-binstall, but it also has many releases for unrelated CLIs. Filter these out with the `tag_regex` tool option:
+
+sh
+
+```
+mise use 'ubi:cargo-bins/cargo-binstall[tag_regex=^\d+\.]'
+```
+
+Now when running `mise ls-remote ubi:cargo-bins/cargo-binstall[tag_regex=^\d+\.]` you should only see versions starting with a number. This command's output is cached, so you will likely need to run `mise cache clear` first.
+
+[Edit this page](https://github.com/jdx/mise/edit/main/docs/dev-tools/backends/ubi.md)
+
+Last updated:
+
+Pager
+
+[Previous pagespm](https://mise.jdx.dev/dev-tools/backends/spm.html)
+
+[Next pagevfox](https://mise.jdx.dev/dev-tools/backends/vfox.html)
+
+MIT License·Copyright © 2026· [![](https://github.com/jdx.png?size=96)jdx.dev](https://jdx.dev)

package/skills/working-with-mise/references/dev-tools/backends/vfox-html.md

@@ -0,0 +1,173 @@
+Vfox Backend
+
+Vfox Backend [​](#vfox-backend)
+
+TIP
+
+vfox is the recommended plugin system for mise. It provides cross-platform support, built-in modules, and a modern hook-based architecture.
+
+Plugins for [vfox](https://github.com/version-fox/vfox) can be used in mise to install tools.
+
+## Why vfox? [​](#why-vfox)
+
+- **Cross-platform** — Lua hooks run on Windows, macOS, and Linux; plugins still need compatible artifacts and platform handling
+- **Built-in modules** — HTTP, JSON, HTML parsing, archive extraction, semver comparison, and logging are all available out of the box, with no external dependencies needed
+- **Security** — [tool plugins](https://mise.jdx.dev/tool-plugin-development.html) support attestation verification (GitHub artifact attestations, cosign signatures, SLSA provenance) for downloaded artifacts. When a tool plugin's `PreInstall` hook returns an `attestation` table, mise verifies it during install and records the result in `mise.lock`, protecting against downgrade attacks on subsequent installs. Backend plugins do not currently support attestation
+- **Structured hooks** — contexts for version discovery, installation, and environment setup; backend plugins can manage multiple tools
+
+The code for this is inside the mise repository at [`./src/backend/vfox.rs`](https://github.com/jdx/mise/blob/main/src/backend/vfox.rs).
+
+## Dependencies [​](#dependencies)
+
+The Lua interpreter is built into mise. A plugin may still invoke external commands or install software that needs system libraries. Read that plugin's requirements; the built-in interpreter does not make every plugin portable.
+
+## Usage [​](#usage)
+
+Install cmake from an explicit vfox plugin and verify the selected executable:
+
+sh
+
+```
+mise use vfox:version-fox/vfox-cmake
+mise exec -- cmake --version
+```
+
+This writes the following project configuration. Add `-g` for a global tool.
+
+toml
+
+```
+[tools]
+"vfox:version-fox/vfox-cmake" = "latest"
+```
+
+The explicit prefix selects that plugin even if the `cmake` registry shorthand prefers another backend.
+
+## Default plugin backend [​](#default-plugin-backend)
+
+Windows excludes asdf from default backend selection. On Linux and macOS, you can exclude it with `mise settings add disable_backends asdf`, but this does not make vfox take precedence over built-in, Packslip, Aqua, or release backends. Check `mise registry cmake` for the shorthand's available sources, or use an explicit `vfox:` identifier when you intend to use a particular plugin.
+
+## Plugins [​](#plugins)
+
+In addition to the standard vfox tool plugins, mise supports backend plugins that can manage multiple tools using the `plugin:tool` format. These plugins are well suited to:
+
+- Installing tools from private repositories
+- Package managers (npm, pip, etc.)
+- Custom tool families
+
+### Example: Plugin Usage [​](#example-plugin-usage)
+
+bash
+
+```
+# Install a plugin
+mise plugins install my-plugin https://github.com/username/my-plugin
+
+# Use the plugin:tool format
+mise install my-plugin:some-tool@1.0.0
+mise use my-plugin:some-tool@latest
+```
+
+### Install from Zip File [​](#install-from-zip-file)
+
+Replace `PLUGIN_NAME` and `HTTPS_ZIP_URL` with the plugin name and archive URL.
+
+bash
+
+```
+# Install a plugin from a zip file over HTTPS
+mise plugins install PLUGIN_NAME HTTPS_ZIP_URL
+# Example: Installing a plugin from a zip file
+mise plugins install vfox-cmake https://github.com/mise-plugins/vfox-cmake/archive/refs/heads/main.zip
+```
+
+### Install from a signed packslip [​](#install-from-a-signed-packslip)
+
+A publisher can distribute a vfox plugin for a non-registry tool as a signed, portable archive. Select that source explicitly, keeping the plugin release separate from tool versions:
+
+sh
+
+```
+mise plugins install vfox:PLUGIN_NAME 'packslip:OWNER/REPO#PLUGIN_VERSION'
+```
+
+Or configure it:
+
+toml
+
+```
+[plugins]
+"vfox:PLUGIN_NAME" = "packslip:OWNER/REPO#PLUGIN_VERSION"
+```
+
+Omit `#PLUGIN_VERSION` to resolve the latest eligible plugin release through the packslip backend. `mise plugins update PLUGIN_NAME` preserves an explicit pin; reinstall with another source version to change it. The installed plugin records its resolved version, artifact digest, and signer. Reinstalling the same version checks those pins again.
+
+This initially supports GitHub repositories publishing `packslip.sigstore.json` with a portable `tar.gz` artifact declaring `extensions.mise.plugin = "vfox"` and no executables or host requirements. The archive must have `metadata.lua` at its root and contain no links, special files, Git metadata, or unsafe paths. Mise uses the packslip backend's signature, digest, signer, and release policy checks. It verifies and stages replacements before removing the previous plugin.
+
+The [bfs publisher example](https://github.com/mise-plugins/vfox-bfs/releases/tag/v0.1.0) demonstrates the format, verified on Linux and macOS. Normal bfs usage continues to use its embedded plugin without downloading a plugin release. Packslip is an explicit source option; existing registry defaults, Git and ZIP sources remain unchanged.
+
+For more information, see:
+
+- [Using Plugins](https://mise.jdx.dev/plugin-usage.html) - End-user guide
+- [Plugin Development](https://mise.jdx.dev/tool-plugin-development.html) - Developer guide
+- [Plugin Template](https://github.com/jdx/mise-tool-plugin-template) - Quick start template for creating plugins
+
+## URL replacements [​](#url-replacements)
+
+The vfox backend honors mise's [`url_replacements`](https://mise.jdx.dev/url-replacements.html) setting for both tool artifact downloads and requests made through the plugin's built-in Lua HTTP module. This includes `http.get`, `http.head`, `http.download_file`, and their `try_*` variants.
+
+After applying URL replacements, vfox also uses mise's [`netrc`](https://mise.jdx.dev/configuration/settings.html#netrc) setting to add HTTP Basic authentication for the destination host. An explicit `Authorization` header supplied by a plugin takes precedence when the request stays on the same origin.
+
+## Tool Options [​](#tool-options)
+
+The following [tool-options](https://mise.jdx.dev/dev-tools/#tool-options) are available for the `vfox` backend—these go in `[tools]` in `mise.toml`.
+
+Traditional vfox `PreInstall` and `PostInstall` hooks receive custom options in the structured `ctx.options` table. Scalar values use mise's existing string representation, while arrays and tables remain structured:
+
+toml
+
+```
+[tools]
+"vfox:example/plugin" = { version = "1.0.0", bundled = false, channels = ["stable", "beta"] }
+```
+
+lua
+
+```
+function PLUGIN:PreInstall(ctx)
+    local bundled = ctx.options.bundled == "false"
+    local channels = ctx.options.channels
+    -- ...
+end
+```
+
+Existing plugins can continue reading custom options from their hook environment with the `MISE_TOOL_OPTS__` prefix. Those variables are available only while mise runs the plugin hook and are not exported to the user's shell. New plugins should use `ctx.options`.
+
+### `install_env` [​](#install-env)
+
+Set environment variables for commands that a vfox plugin starts with `cmd.exec` during install hooks. vfox's built-in Lua HTTP, archive, and JSON helpers do not use these variables directly.
+
+toml
+
+```
+[tools]
+"vfox:version-fox/vfox-cmake" = { version = "latest", install_env = { HTTPS_PROXY = "http://proxy.example" } }
+```
+
+### Install dependencies [​](#install-dependencies)
+
+Plugin authors should declare intrinsic install requirements with `PLUGIN.depends` in `metadata.lua`. Users can supplement those declarations with the [`depends` tool option](https://mise.jdx.dev/dev-tools/#tool-dependencies). Matching configured tools from both sources share one install dependency context: they are ordered before the dependent tool, and their paths and `tools = true` values are available to install hooks launched through `os.execute` or `cmd.exec`.
+
+Declarations do not configure or automatically install a tool. A matching configured dependency must resolve and be installed; an unconfigured dependency can still be supplied by the existing system or configuration `PATH`. `io.popen` does not receive this install environment.
+
+[Edit this page](https://github.com/jdx/mise/edit/main/docs/dev-tools/backends/vfox.md)
+
+Last updated:
+
+Pager
+
+[Previous pageubi](https://mise.jdx.dev/dev-tools/backends/ubi.html)
+
+[Next pageOverview](https://mise.jdx.dev/bootstrap.html)
+
+MIT License·Copyright © 2026· [![](https://github.com/jdx.png?size=96)jdx.dev](https://jdx.dev)