10 Windows Tools for Technical Operations

My starting list is Windows Terminal, PowerShell, Git, GitHub CLI, OpenSSH, curl, ripgrep, Python, Node.js, and WinGet. All ten are free to install. You do not need every one for every job; these are the roles I would cover on a technical workstation.

Find the executable before debugging it

Run this in PowerShell. Missing commands produce errors; that is useful information, not a reason to install everything listed.

Get-Command git, gh, ssh, curl.exe, rg, python, node, winget -All |
  Select-Object Name, CommandType, Source, Version

Multiple results reveal command-name collisions or several installations. Check the command in the shell where the failure occurs: an integrated terminal may inherit a different PATH. The Version column is command metadata, not a reliable substitute for each program’s own version output.

1. Windows Terminal: keep the shell visible

Terminal hosts shells; it does not make their syntax interchangeable. A tab might contain PowerShell, Command Prompt or a Linux shell through WSL. Check that before copying a command. In particular, a trailing backslash from a Bash example does not continue a PowerShell command onto the next line.

2. PowerShell: inspect objects without parsing a screen

Keep objects intact while filtering them. For example, in a directory you own:

Get-ChildItem -File |
  Sort-Object Length -Descending |
  Select-Object -First 10 Name, Length, LastWriteTime

This lists the ten largest files in that directory, not its subdirectories. It changes nothing. Add recursion only when the wider scope is intentional; a large tree or network share can be slow to enumerate.

3. Git: review the worktree and the index separately

git status --short
git diff --stat
git diff --cached --stat
git diff --check
git diff --cached --check

Run these inside the repository. Ordinary diff examines unstaged tracked changes; cached diff examines staged changes. Neither includes the contents of untracked files, so read the status output too. The check commands catch whitespace errors and conflict markers in the changes they examine. They do not test the program.

4. GitHub CLI: check the hosted result

A local commit cannot tell you whether its pull request passed CI. GitHub CLI covers that separate service:

gh pr checks 123

Replace 123 with the pull-request number and run it in the intended GitHub repository after authenticating. Inspect failures rather than treating a nonzero exit as a broken CLI. Avoid pasting authentication tokens or private check logs into a public issue.

5. OpenSSH: use a named destination

An SSH host alias keeps destination settings together instead of scattering usernames and ports through scripts. Verify the host key through a trusted channel on first connection. An unexpected changed-key warning needs investigation, not a command that disables checking. For browser-only access through a server, see the dynamic-forwarding guide.

6. curl: distinguish HTTP failure from transport failure

This single-line command works in PowerShell on Windows and makes a GET request to a public page:

curl.exe --silent --show-error --fail --connect-timeout 10 --max-time 30 --dump-header - --output NUL https://example.com/
$LASTEXITCODE

Headers remain visible; the body is discarded. A successful transfer returns zero, while --fail makes HTTP errors such as 404 return a failure code. Redirects are not followed here: inspect the Location header before choosing to add --location. Use the URL you need to diagnose and avoid sharing headers from authenticated requests, which can contain sensitive values.

7. ripgrep: search the files that own the setting

rg -n --glob '*.yaml' --glob '*.yml' 'timeout|retry' .

Run this from the configuration tree you want to inspect. It finds matching lines, not effective runtime values. Default filtering can exclude ignored or hidden files; generated configuration and database-backed settings may live elsewhere entirely. Verify the running service after finding the source.

8. Python and 9. Node.js: follow the project’s runtime

I would not install both merely to complete a checklist. Use the runtime the repository requires, then check its version in the same environment that runs the tests:

python --version
node --version

A working interpreter does not prove that dependencies are installed or that the version is supported by the project. Follow its lockfile and setup instructions. Be cautious with unfamiliar install commands: package installation can execute code.

10. WinGet: record packages, not a recovery promise

WinGet can export installed packages it can match to its sources. Review warnings about unmatched applications. An export does not preserve documents, local repositories, SSH keys, application settings or licenses. Keep those in the appropriate backup process; a list of installers cannot restore a workstation by itself.

On a new machine, I would first check command resolution, then run the project’s tests, then verify its remote dependencies. That catches more useful failures than reproducing a long list of version numbers from somebody else’s PC.

References: PowerShell parsing, Git diff, GitHub CLI checks, OpenSSH, curl options, ripgrep, and WinGet export.