Mise Configurator

Overview

This skill generates clean, production-ready mise.toml configurations for local development environments and CI/CD pipelines.

It helps standardize runtime versions, simplify onboarding, replace legacy version managers like asdf, nvm, and pyenv, and create reproducible multi-language environments with minimal setup effort.

When to Use This Skill

• Use when you need to create or update a mise.toml
• Use when working with Node.js, Python, Go, Rust, Java, Bun, Terraform, or mixed stacks
• Use when the user asks about CI/CD runtime setup using mise
• Use when migrating from .tool-versions, asdf, nvm, or pyenv
• Use when standardizing tool versions across teams or monorepos

How It Works

Step 1: Detect Project Context

Inspect available repository files such as:

• package.json
• pnpm-lock.yaml
• pyproject.toml
• requirements.txt
• go.mod
• Cargo.toml
• .tool-versions
• Dockerfile
• GitHub Actions or CI files

Infer languages, package managers, and pinned versions.

Step 2: Generate mise.toml

Create a minimal, valid, copy-paste-ready configuration using:

• existing pinned versions when found
• explicit user-provided target versions when absent
• practical defaults for developer productivity
• concrete pinned versions in shared production configs

Step 3: Add Bootstrap Commands

Provide setup commands such as:

bash
mise trust
mise install

Step 4: Generate CI/CD Integration

If requested, generate pipeline examples using mise with caching and runtime installation.

Examples

Example 1: Node.js + pnpm Project

toml
[tools]
node = "22.11.0"
pnpm = "9.15.0"

Example 2: Python + GitHub Actions

toml
[tools]
python = "3.12.7"
poetry = "1.8.4"

yaml
steps:
  - uses: actions/checkout@v4
  - uses: jdx/mise-action@v2
  - run: poetry install
  - run: pytest

Best Practices

• ✅ Respect versions already pinned in the repository

• ✅ Keep configs minimal and readable

• ✅ Prefer stable runtime releases

• ✅ Generate CI examples with caching

• ✅ Ask for target versions before pinning when the repository does not already declare them

• ❌ Do not use floating latest or lts aliases in shared production configs unless explicitly requested

• ❌ Do not over-engineer unnecessary tool entries

• ❌ Do not ignore existing lockfiles or version files

Limitations

• This skill does not replace environment-specific validation, testing, or expert review.

• Stop and ask for clarification if required inputs, permissions, or safety boundaries are missing.

• Runtime availability may vary by OS, shell, or CI platform.

• Some plugins or niche tools may require manual adjustment.

Security & Safety Notes

• Review generated shell commands before execution.

• Confirm CI/CD permissions before modifying pipelines.

• Validate runtime versions against production requirements.

• Use only in authorized repositories and environments.

Common Pitfalls

• Problem: Wrong runtime version selected

Solution: Check repository lockfiles and pinned versions first.

• Problem: CI installs are slow

Solution: Enable cache layers and reuse mise cache directories.

• Problem: Tool missing from registry

Solution: Verify plugin support or install manually.

Related Skills

• @docker-expert - Use when building containerized development environments

• @github-actions-templates - Use for advanced workflow automation

• @monorepo-architect - Use for large multi-package repositories