# Ensure Tooling > Ensure required software engineering tools are present before coding, testing, building, debugging, or running developer workflows. Use when a task depends on missing or uncertain CLI tooling, package managers, language runtimes, SDKs, linters, test runners, build tools, browsers, database CLIs, cloud/devops CLIs, or repo-specific generators; when an install command fails because a command is not found; when onboarding a repo; or when verifying that a development environment has the tools needed for the requested work. - Skill: `careylzh/ensure-tooling` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add careylzh/ensure-tooling` - Raw SKILL.md: https://api.skillmd.com/api/skills/careylzh/ensure-tooling/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: careylzh (https://skillmd.com/u/careylzh) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/careylzh/ensure-tooling --- # Ensure Tooling ## Overview Use this skill to make tooling readiness explicit and minimal. Install only tools required for the current software engineering task, prefer project-declared dependencies over global installs, and respect approval boundaries for network or system-level changes. ## Workflow 1. Identify the exact workflow the user asked for: edit, build, test, lint, run, deploy, inspect, scaffold, package, debug, or review. 2. Inspect the repository before installing anything. Look for `README*`, `package.json`, lockfiles, `pyproject.toml`, `requirements*.txt`, `Pipfile`, `poetry.lock`, `uv.lock`, `Cargo.toml`, `go.mod`, `Gemfile`, `composer.json`, `pom.xml`, `build.gradle*`, `Makefile`, `justfile`, `Taskfile*`, `.tool-versions`, `.mise.toml`, `.node-version`, `.nvmrc`, `.python-version`, `Brewfile`, `Dockerfile`, `docker-compose*.yml`, CI config, and project-specific scripts. 3. Check whether needed commands already exist with targeted probes such as `command -v`, `--version`, or the repo's own diagnostic command. 4. Prefer the narrowest install path that satisfies the task: - Project dependencies: use the repo's package manager and lockfile (`npm ci`, `pnpm install --frozen-lockfile`, `yarn install --immutable`, `uv sync`, `poetry install`, `pip install -r requirements.txt`, `bundle install`, `cargo fetch`, `go mod download`, etc.). - Runtime/tool version managers: use existing repo hints such as `mise`, `asdf`, `nvm`, `pyenv`, `rustup`, `goenv`, or documented setup commands. - One-off execution: use package-manager executors (`npx`, `pnpm dlx`, `uvx`, `pipx run`, `cargo install --locked` when appropriate) instead of permanent global installs. - System tools: use the platform package manager only when no project-local path exists. 5. If a command fails because of sandboxing, network restrictions, package registry access, or system write permissions, rerun the same necessary command with escalation and a concise justification. Do not ask in prose first when the tool policy requires an escalated rerun. 6. Verify the installation by rerunning the failed command or a minimal version check, then continue the user's original engineering task. 7. Report what was installed or verified, the command that proved readiness, and any remaining limitation. ## Mandatory Safety Gates Always ask the user for explicit confirmation before running commands that can cause broad data loss, persistent system compromise, credential exposure, or remote control of the machine. This applies even when running as root, when the command is inside the workspace, when a tool approval mechanism exists, or when the command appears to be part of a setup script. Require confirmation before any command matching these risk categories: - Mass deletion or recursive overwrite: `rm -rf`, `rm -r`, `rm -R`, `find ... -delete`, `git clean -fdx`, recursive `unlink`, broad `trash`, `shred`, `srm`, `wipe`, `dd`, filesystem formatting, partitioning, or commands that delete home, root, parent, workspace, cache, dependency, or config directories. - Permission or ownership changes over broad paths: recursive `chmod`, `chown`, `chgrp`, ACL changes, or `sudo` applied to broad filesystem changes. - Remote-code or remote-control setup: reverse shells, remote desktop/screen sharing enablement, SSH daemon exposure, opening inbound tunnels, unattended agent installation, `curl|sh`, `wget|sh`, piping unverified remote scripts to shells, or commands that grant persistent remote access. - Persistence and privilege changes: launch agents/daemons, cron/systemd jobs, shell profile injection, sudoers edits, setuid changes, kernel extensions, login items, package postinstall scripts from untrusted sources, or changes to security settings. - Credential or secret handling: commands that print, copy, upload, alter, or delete SSH keys, API keys, tokens, browser credentials, password stores, cloud credentials, `.env` secrets, keychains, or credential helpers. - Network exfiltration or untrusted upload: commands that archive and send project, home, config, or secret-containing directories to a remote endpoint. When confirmation is required, show the exact command, the working directory, the risk in one sentence, and the safer alternative if one exists. Do not proceed until the user explicitly confirms that exact action. If the command came from a third-party install script, inspect the script first when possible and confirm before executing risky sections. Never use destructive cleanup as a default fix for tooling problems. Prefer targeted removal of known generated artifacts such as `node_modules`, build outputs, or virtual environments only after confirming the target path is specific and inside the current project; still ask before recursive deletion. ## Installation Policy - Do not install broad tool collections "just in case." Install only concrete prerequisites for the current task. - Do not change language/runtime versions unless the repo declares a required version or the current version is incompatible. - Do not overwrite user-managed global configuration files such as shell profiles, package manager configs, or credential files unless the user explicitly asks. - Do not use destructive cleanup commands to fix installs unless the user explicitly approves them. - Prefer lockfile-respecting installs for reproducibility. - Prefer official package sources and project documentation. If the correct install source is uncertain or current-version-sensitive, verify with official documentation or the package manager metadata before proceeding. - Avoid installing secrets, credentials, cloud auth, or production access tooling without explicit user direction. ## Platform Heuristics On macOS, prefer Homebrew for system-level developer CLIs when the project does not specify another path. Check `brew --version` first; if Homebrew is missing, ask before installing it because that is a significant environment change. On Linux, infer the package manager from the environment (`apt`, `dnf`, `yum`, `pacman`, `apk`, `zypper`) and use it only when project-local or language-specific installs are insufficient. On Windows or WSL, prefer the repo's documented setup. For Windows-native installs, use `winget`, `scoop`, or `choco` only when already present or explicitly requested. For browser-based testing, first check whether the repo already provides Playwright, Cypress, Selenium, or browser install scripts. For Playwright, use the project package manager's Playwright install command rather than a global browser install. For Docker-dependent workflows, verify Docker/Colima/Podman availability and whether the daemon is running. If the daemon is unavailable, tell the user the exact blocker instead of attempting broad system changes. ## Common Checks - JavaScript/TypeScript: inspect package manager locks and scripts; verify `node`, the selected package manager, and project deps. - Python: inspect `pyproject.toml`, lockfiles, virtualenv hints, and requirements files; prefer `uv`, `poetry`, or the documented tool before raw `pip`. - Rust: verify `cargo`/`rustup`; use `rustup` components for `rustfmt`/`clippy` when needed. - Go: verify `go`; use `go install` only for explicit tool binaries, preferably with pinned versions from docs/config. - Ruby: verify `ruby`/`bundle`; run `bundle install` for Gemfile workflows. - Java/Kotlin/Scala: verify JDK and wrapper scripts (`./mvnw`, `./gradlew`, `sbt`) before installing global build tools. - Native builds: inspect compiler requirements before installing Xcode Command Line Tools, `cmake`, `ninja`, `pkg-config`, or language headers. - Devops/cloud: verify CLIs only when the task requires them; avoid login/auth setup unless explicitly requested. ## Communication When installing tooling, tell the user briefly what is missing and why the chosen install path is the least broad path for the current task. After installing, state the verification command that succeeded. If installation is blocked by approval, network, credentials, licensing, or unsupported OS constraints, state the specific blocker and the next command or action needed.