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.