ag-mise-configurator

# 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