{ "count": 320, "clis": [ { "slug": "ollama", "name": "Ollama", "description": "Local model runtime CLI for pulling models, serving a local API with OpenAI-compatible endpoints, creating Modelfile-based variants, and launching supported integrations.", "long_description": "Ollama is a local model runtime and control CLI for pulling models, running them locally or through Ollama Cloud, and exposing them over a local HTTP API. It also packages customized models and can launch supported coding tools against that runtime.\n\n## What It Enables\n- Pull, run, stop, and inspect local or cloud-backed models from the shell, including interactive chat and embedding generation.\n- Start a local Ollama server that exposes native and OpenAI-compatible JSON APIs for chat, embeddings, structured outputs, vision, and tool-calling requests.\n- Create and import customized models from `Modelfile`, Safetensors, or GGUF assets, then launch supported tools like `codex` or `claude` against the local runtime.\n\n## Agent Fit\n- Agents usually get the most value from `ollama serve` plus the JSON API, with the CLI handling model lifecycle, setup, and simple one-shot runs.\n- `ollama run` accepts piped stdin, supports `--format json`, and embedding models print a JSON array, so it can participate in shell pipelines even without wrapping the HTTP API.\n- Fit is mixed rather than fully deterministic: the default entrypoint is a TUI, model responses are still probabilistic, and unattended use depends on local hardware limits or Ollama account auth for cloud flows.\n\n## Caveats\n- Large local models are constrained by available CPU, GPU, memory, and disk; cloud models require sign-in or API-key setup.\n- The bare `ollama` and `ollama launch` flows are human-oriented Bubble Tea menus, so automation should call explicit subcommands or the API directly.", "category": "ai-agents", "install": "curl -fsSL https:\/\/ollama.com\/install.sh | sh", "github": "https:\/\/github.com\/ollama\/ollama", "website": "https:\/\/docs.ollama.com\/cli", "source_url": null, "stars": 164442, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": true, "source_type": "github", "vendor_name": "Ollama" }, { "slug": "yt-dlp", "name": "yt-dlp", "description": "Media download CLI for fetching video, audio, subtitles, and metadata from YouTube and thousands of supported sites.", "long_description": "yt-dlp is a media download CLI for fetching video, audio, subtitles, thumbnails, and metadata from YouTube and thousands of supported sites. It also works as an inspection tool for formats, subtitles, and playlist metadata before you decide what to download.\n\n## What It Enables\n- Download videos, playlists, livestream captures, or audio-only files from supported sites with explicit format selection, output templates, and post-processing steps.\n- Inspect available formats, subtitles, thumbnails, and extractor support without downloading first, then choose the right variant for a scripted workflow.\n- Write `.info.json` metadata, subtitles, thumbnails, and comments to disk, or load prior info JSON files to replay download steps with preserved metadata.\n\n## Agent Fit\n- JSON output via `--dump-json` and `--dump-single-json`, plus simulate and list modes, makes inspect-decide-download loops straightforward in the shell.\n- The command surface is mostly flag-driven and non-interactive, but some sites still require cookies, credentials, browser-derived state, or extra runtime components.\n- Best fit is media capture and archive automation where an agent needs direct file outputs and metadata, not general browser or content management workflows.\n\n## Caveats\n- Authenticated or rate-limited sites may require browser cookies, passwords, or provider-specific options, which makes unattended runs environment-dependent.\n- Full YouTube support and post-processing often depend on external tools such as `yt-dlp-ejs`, a JavaScript runtime, and `ffmpeg`.", "category": "media", "install": "python -m pip install -U --pre \"yt-dlp[default]\"", "github": "https:\/\/github.com\/yt-dlp\/yt-dlp", "website": "https:\/\/github.com\/yt-dlp\/yt-dlp\/wiki", "source_url": null, "stars": 150175, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "go", "name": "Go", "description": "Official Go toolchain CLI for building, testing, running, and inspecting Go packages, modules, and workspaces.", "long_description": "Go is the official command-line tool for working with Go codebases and the Go toolchain. It handles package builds, tests, runs, module and workspace maintenance, environment inspection, and access to bundled tools from one entrypoint.\n\n## What It Enables\n- Build, run, test, benchmark, and install Go packages or commands across local packages, modules, and target platforms.\n- Inspect package graphs, module metadata, workspace state, environment settings, and binary build info with commands like `go list`, `go env`, `go mod`, `go work`, and `go version -m`.\n- Initialize or maintain `go.mod` and `go.work`, download or verify dependencies, generate code, and invoke bundled or module-defined tools.\n\n## Agent Fit\n- Core workflows are shell-friendly: commands are mostly non-interactive, work against explicit paths or package patterns, and return stable exit codes for CI or agent loops.\n- Structured output is substantial rather than universal, with JSON on `go env`, `go list`, `go mod download`, `go mod edit`, `go work edit`, `go version -m`, `go test`, and build-style `-json` output.\n- Automation still depends on local toolchain state, module graph, and sometimes network access, and many everyday commands remain text-first.\n\n## Caveats\n- `README.md` identifies `golang\/go` as an official mirror; the canonical Git repository is `go.googlesource.com\/go`.\n- Official install docs point to platform-specific downloads and installers, so there is no single upstream shell install command to recommend.", "category": "package-managers", "install": null, "github": "https:\/\/github.com\/golang\/go", "website": "https:\/\/pkg.go.dev\/cmd\/go", "source_url": "https:\/\/go.dev\/", "stars": 132961, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Go" }, { "slug": "shadcn", "name": "shadcn CLI", "description": "CLI for scaffolding shadcn\/ui projects, adding registry items, and inspecting project or registry metadata.", "long_description": "shadcn CLI is the terminal interface for setting up shadcn\/ui projects and working with shadcn-compatible registries. It scaffolds frontend apps, inspects available components or blocks, and writes source files directly into your repo.\n\n## What It Enables\n- Initialize or reconfigure a frontend project with templates, presets, base library selection, monorepo support, and generated `components.json` config.\n- Search registries, view registry payloads before install, and fetch docs, examples, or project info for follow-up edits.\n- Add components, blocks, themes, or other registry items to a codebase, or build JSON output for your own shadcn-compatible registry.\n\n## Agent Fit\n- `search` and `view` return JSON, and `info --json` or `docs --json` expose local project state and component references in machine-readable form.\n- `add --dry-run`, `--diff`, and `--view` support inspect-change-verify loops before files are written.\n- Best when an agent is already inside a React or Tailwind repo using shadcn-compatible registries; the value is narrower outside that ecosystem, and `init` or `mcp init` can still prompt or rewrite local config.\n\n## Caveats\n- It is frontend-specific and file-writing by design, so unattended use should pair `--dry-run` or `--diff` with repo review.\n- Some flows depend on project detection, `components.json`, environment-backed private registries, or confirmation when overwriting existing config.", "category": "dev-tools", "install": "npx shadcn@latest init", "github": "https:\/\/github.com\/shadcn-ui\/ui", "website": "https:\/\/ui.shadcn.com\/docs\/cli", "source_url": null, "stars": 108525, "language": "TypeScript", "has_mcp": true, "has_skill": true, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "deno", "name": "Deno", "description": "JavaScript and TypeScript runtime CLI with built-in dependency management, tasks, linting, testing, docs, and executable compilation.", "long_description": "Deno is a JavaScript and TypeScript runtime CLI that bundles common project tooling into one binary. It covers code execution plus package, task, quality, testing, documentation, and compilation workflows for Deno projects.\n\n## What It Enables\n- Run local or remote JavaScript and TypeScript programs, scripts, and configured tasks with explicit file, network, env, and subprocess permissions.\n- Add, install, remove, and update JSR or npm dependencies, inspect module or cache state, and work from a project's `deno.json` or `package.json`.\n- Format, lint, test, benchmark, measure coverage, generate docs, and compile a script into a self-contained executable.\n\n## Agent Fit\n- Subcommands are broad but clear, so agents can stay inside one CLI for inspect-change-verify loops across a Deno codebase.\n- Structured output is real where inspection matters most: `deno info --json`, `deno doc --json`, `deno lint --json`, and unstable `deno bench --json`; tests and coverage also support JUnit, TAP, and lcov outputs.\n- Best for agents operating on a checked-out project; `run`, `task`, `install`, and remote module execution can execute arbitrary code, so permission flags and trust boundaries need deliberate handling.\n\n## Caveats\n- Many automation flows depend on local config, cache state, and explicit `--allow-*` or `--no-prompt` flags.\n- Core execution and package-management output is still mostly text-first, so structured parsing is strongest on inspection and reporting commands rather than every workflow.", "category": "package-managers", "install": "curl -fsSL https:\/\/deno.land\/install.sh | sh", "github": "https:\/\/github.com\/denoland\/deno", "website": "https:\/\/deno.com\/", "source_url": null, "stars": 106338, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "deno", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Deno" }, { "slug": "gemini-cli", "name": "Gemini CLI", "description": "Google's official terminal coding agent for repo analysis, code edits, shell actions, and headless JSON runs.", "long_description": "Gemini CLI is Google's terminal coding agent for working inside a local repository through an interactive session or headless one-shot run. It wraps model-driven coding help with built-in file, shell, web, MCP, and skill surfaces.\n\n## What It Enables\n- Inspect and edit a local codebase, run shell commands, read or write files, and use built-in web search or fetch tools from one terminal session.\n- Run one-shot coding or repo prompts in scripts, CI helpers, or wrappers, with structured JSON or streaming JSON output for downstream parsing.\n- Extend the base agent with MCP servers, workspace context files, and reusable skills for project-specific workflows.\n\n## Agent Fit\n- Headless mode has explicit JSON and JSONL formats, documented exit codes, and flags for approval mode, model selection, session resume, and included directories.\n- The default experience is still an interactive TUI with auth, confirmation, and trust flows, so unattended usage needs preconfiguration and remains less deterministic than service-specific CLIs.\n- Best fit when you want a higher-level repo automation loop in the shell; it can also connect to MCP-based setups when that integration model is needed.\n\n## Caveats\n- Automation should use `--prompt` or `--output-format` explicitly because docs disagree on whether positional prompts default to one-shot or interactive mode in a TTY.\n- Browser-based sign-in and tool approval or trust settings can block unattended runs until you configure auth and policies.", "category": "agent-harnesses", "install": "npm install -g @google\/gemini-cli", "github": "https:\/\/github.com\/google-gemini\/gemini-cli", "website": "https:\/\/geminicli.com", "source_url": "https:\/\/geminicli.com", "stars": 96891, "language": "TypeScript", "has_mcp": true, "has_skill": true, "has_json": true, "brand_icon": "google", "is_official": true, "is_tui": true, "source_type": "github", "vendor_name": "Google" }, { "slug": "bun", "name": "Bun", "description": "JavaScript and TypeScript runtime CLI with package manager, test runner, bundler, and `bunx` package execution.", "long_description": "Bun is an all-in-one JavaScript and TypeScript toolchain shipped as a single `bun` binary. It combines runtime execution, package management, testing, bundling, and one-off package execution for local app and monorepo workflows.\n\n## What It Enables\n- Run TypeScript or JavaScript files and `package.json` scripts directly, including workspace-wide script runs in monorepos.\n- Install, update, audit, and inspect npm dependencies, including filtered workspace installs, dependency explanations, and registry metadata queries.\n- Run tests, emit JUnit for CI, build bundles, and execute npm package binaries on demand with `bunx`.\n\n## Agent Fit\n- The main subcommands are clear and mostly non-interactive, so Bun fits script, CI, and local agent loops around existing JS or TS repos.\n- Structured output exists where inspection matters, including `bun info --json`, `bun audit --json`, and JUnit test reports, but run\/install\/build output is otherwise mostly human-readable.\n- Best for agents operating inside a checked-out project; `bun run` and package scripts execute arbitrary repo code, so side effects and project trust boundaries matter.\n\n## Caveats\n- `bun init`, `bun create`, and interactive dependency updates can prompt by default, so unattended setup needs the right flags or an existing project.\n- Compatibility aims at Node.js projects, but behavior still depends on Bun-specific runtime support, lockfile state, and project configuration.", "category": "package-managers", "install": "curl -fsSL https:\/\/bun.com\/install | bash", "github": "https:\/\/github.com\/oven-sh\/bun", "website": "https:\/\/bun.com\/docs", "source_url": null, "stars": 87970, "language": "Zig", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "bun", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Oven" }, { "slug": "hugo", "name": "Hugo", "description": "Static site generator CLI for scaffolding projects, previewing changes locally, and building or deploying static sites.", "long_description": "Hugo is a static site generator CLI for building websites from local content, templates, and configuration. It covers project scaffolding, local preview, production builds, and some deployment or migration tasks in the same tool.\n\n## What It Enables\n- Create new sites, themes, and content files, using archetypes to stamp consistent front matter and file structure.\n- Run a local development server with rebuild and live reload, then render the finished site to static HTML, feeds, and assets in one command.\n- Inspect content and effective configuration with `hugo list` and `hugo config`, import Jekyll content, and deploy supported builds to S3, GCS, or Azure.\n\n## Agent Fit\n- Works well for repo-local automation because the main commands are explicit, non-interactive by default, and map cleanly to edit-build-verify loops.\n- Machine-readable output exists but is limited: `hugo config --format json` and `hugo config mounts` are JSON, while `hugo list` emits CSV and build or server output is mostly text logs.\n- Best fit when an agent is changing content, templates, or config inside a Hugo repo; it is less useful as a general publishing API for hosted CMS workflows.\n\n## Caveats\n- `hugo deploy` is only compiled into extended\/deploy builds, so not every installed binary has the same deployment surface.\n- Most automation value depends on the conventions inside a specific site repo, including archetypes, theme or module setup, and template logic.", "category": "dev-tools", "install": "brew install hugo", "github": "https:\/\/github.com\/gohugoio\/hugo", "website": "https:\/\/gohugo.io\/", "source_url": null, "stars": 86961, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "hugo", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "playwright", "name": "Playwright CLI", "description": "Browser testing and automation CLI for running Playwright tests, recording flows, and inspecting reports or traces.", "long_description": "Playwright is a browser testing and automation CLI centered on Playwright Test, with commands to run suites, record flows, install browser runtimes, and inspect reports or traces. It fits best as a verification and browser-debug surface for web apps rather than a generic shell-first scraping tool.\n\n## What It Enables\n- Run end-to-end suites across Chromium, Firefox, and WebKit with filtering, sharding, retries, and headed or headless execution.\n- Record user flows with `codegen`, then inspect failures through HTML reports, trace viewer, screenshots, video, and other Playwright artifacts.\n- Set up repo-local agent definitions with `init-agents`, and use the built-in browser or test-runner MCP surfaces when agent-assisted workflows are needed.\n\n## Agent Fit\n- Exit codes, non-interactive test flags, and CI-oriented commands make `playwright test` a solid verify loop for agents after UI or backend changes.\n- Structured output is real but concentrated in reporters such as `--reporter=json`; many other commands open browsers, HTML UIs, or inspectors instead of returning JSON.\n- Useful both directly and through the built-in MCP surfaces, but the core CLI is strongest for test execution and debugging rather than arbitrary one-off browser control.\n\n## Caveats\n- Browser-using commands need both the Playwright package and downloaded browser binaries; downloading browsers alone is not a full install path.\n- `codegen`, `show-report`, `show-trace`, and `--ui` are interactive or UI-heavy, so unattended workflows usually revolve around `playwright test` and reporter artifacts.", "category": "testing", "install": "npm i -D @playwright\/test", "github": "https:\/\/github.com\/microsoft\/playwright", "website": "https:\/\/playwright.dev\/", "source_url": null, "stars": 83738, "language": "TypeScript", "has_mcp": true, "has_skill": true, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Microsoft" }, { "slug": "uv", "name": "uv", "description": "Python workflow CLI for managing projects, syncing environments, installing packaged tools, and handling Python versions.", "long_description": "uv is a Python workflow CLI that combines project management, package installation, virtual environments, tool execution, and Python version management. It covers both high-level `pyproject.toml` workflows and lower-level pip-style environment commands from one shell surface.\n\n## What It Enables\n- Create Python projects, add or remove dependencies, lock them, sync environments, and run commands against the managed project environment.\n- Install Python versions and invoke Python-packaged CLIs either ephemerally with `uvx` or as persistent user-level tools.\n- Inspect packages, export lock data, build distributions, and publish packages without switching between separate Python workflow tools.\n\n## Agent Fit\n- One non-interactive-first CLI spans setup, inspection, and mutation tasks across Python repos, environments, and toolchains, so agents do not need to juggle multiple package managers.\n- Structured output is available on inspect surfaces such as `uv pip list --format json`, `uv version --output-format json`, and source-defined JSON modes for `python list` and auth helper flows.\n- Some broader JSON output surfaces are still tied to the `json-output` preview feature, and commands that touch credentials or existing directories may still prompt unless you pass explicit flags or preconfigure state.\n\n## Caveats\n- It is specific to Python packaging and interpreter workflows, so it is a poor fit outside Python projects or Python-packaged tools.\n- Commands that publish packages, download interpreters, or access package indexes depend on network access and can mutate local environments, lockfiles, or remote package state.", "category": "package-managers", "install": "curl -LsSf https:\/\/astral.sh\/uv\/install.sh | sh", "github": "https:\/\/github.com\/astral-sh\/uv", "website": "https:\/\/docs.astral.sh\/uv\/", "source_url": null, "stars": 80496, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "uv", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Astral" }, { "slug": "fzf", "name": "fzf", "description": "Terminal fuzzy finder for filtering lists, selecting matches, and attaching previews or actions in shell workflows.", "long_description": "fzf is a terminal fuzzy finder and interactive Unix filter for narrowing arbitrary line-oriented input, selecting items, and attaching previews or actions to the current match. It is most useful as shell plumbing around files, history, processes, Git refs, log streams, and other lists you already know how to generate.\n\n## What It Enables\n- Filter arbitrary stdin or walked files, select one or many matches, and print the chosen lines or NUL-delimited paths back to the shell.\n- Add previews, key bindings, reload actions, or `become(...)` handoffs so one selection UI can open editors, kill processes, switch Git branches, or launch other commands.\n- Embed fuzzy picking into shell history search, tab completion, tmux popups, Vim or Neovim commands, and ripgrep-driven code or log search flows.\n\n## Agent Fit\n- `--filter`, `--select-1`, `--exit-0`, `--print0`, and stable stdout or exit behavior make it usable in scripts when you want fuzzy matching without opening the TUI.\n- The built-in `--listen` server can expose current matches and selection state as JSON and accept actions, but that path is experimental and tied to a running interactive session.\n- Fit is mixed overall: the main product is a human-operated selector, so agents usually get more value from its non-interactive filter mode or from pairing it with a user than from driving the interface headlessly.\n\n## Caveats\n- Most high-value workflows still assume a real terminal and a human driving the picker, even when the surrounding pipeline is scripted.\n- Normal output is plain text; the JSON status API only exists behind `--listen` while fzf is running.", "category": "file-management", "install": "brew install fzf", "github": "https:\/\/github.com\/junegunn\/fzf", "website": "https:\/\/junegunn.github.io\/fzf\/", "source_url": null, "stars": 78403, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "claude-code", "name": "Claude Code", "description": "Anthropic's terminal-native coding agent for repo understanding, edits, tests, and git workflows.", "long_description": "Claude Code is a terminal coding agent for working inside a local repository. It combines prompt-driven code assistance with direct access to files, shell commands, git workflows, plugins, and MCP-connected tools.\n\n## What It Enables\n- Inspect a repo, request edits, run tests or shell commands, and let the agent apply changes in the same terminal session.\n- Resume or fork sessions, use project or user skills, and install plugins to capture repeatable development workflows.\n- Run one-off prompts with `--print` for scripted code review, patch generation, summaries, or schema-checked structured output.\n\n## Agent Fit\n- Headless mode supports `--print`, JSON and stream-json output, JSON schema validation, stdin input formats, and explicit tool permission flags.\n- Unattended use is possible, but the default product is still an interactive agent shell with auth, approvals, and session state that usually need preconfiguration.\n- Best fit is as a higher-level repo automation loop when you want an agent to inspect, change, and verify code directly from the shell; it can also connect to MCP-based setups when needed.\n\n## Caveats\n- Behavior is model-driven rather than subcommand-driven, so repeatability is weaker than with narrow deterministic service CLIs.\n- Login, permissions, plugins, and MCP servers can trigger interactive setup unless you lock them down in settings before automation.", "category": "agent-harnesses", "install": "npm install -g @anthropic-ai\/claude-code", "github": "https:\/\/github.com\/anthropics\/claude-code", "website": "https:\/\/docs.anthropic.com\/en\/docs\/claude-code\/overview", "source_url": "https:\/\/docs.anthropic.com\/en\/docs\/claude-code\/overview", "stars": 74911, "language": "TypeScript", "has_mcp": true, "has_skill": true, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": true, "source_type": "github", "vendor_name": "Anthropic" }, { "slug": "redis-cli", "name": "redis-cli", "description": "Official Redis CLI for running commands, scanning keys, exporting data, and managing Redis servers or clusters.", "long_description": "`redis-cli` is Redis's official command-line client for talking directly to a Redis server or cluster from the shell. Beyond ad hoc REPL use, it includes non-interactive modes for key scanning, data export, piped writes, Lua evaluation, and cluster administration.\n\n## What It Enables\n- Run Redis commands against local or remote instances to inspect keys, values, config, stats, and health from the shell.\n- Scan keyspaces and sample big, hot, or memory-heavy keys to debug production behavior or find cleanup targets.\n- Pipe bulk writes, export RDB snapshots or functions, run Lua scripts, and perform cluster management operations from scripts or incident tooling.\n\n## Agent Fit\n- Any Redis command can be executed non-interactively, and `-e` can surface command failures with a nonzero exit code for automation loops.\n- `--json` and `--quoted-json` provide structured output, but plain text remains the default and some monitoring modes are more human-oriented unless you force machine-friendly flags.\n- Useful when an agent already knows which Redis instance or cluster to target; it is a thin control surface over a live datastore, not a safer workflow abstraction.\n\n## Caveats\n- It defaults to an interactive REPL when no command is supplied, and some cluster operations still prompt unless you pass `--cluster-yes`.\n- This is direct access to live Redis data and topology, so writes, deletes, RDB export, and cluster fixes need credentials, network access, and guardrails.", "category": "databases", "install": "brew install redis", "github": "https:\/\/github.com\/redis\/redis", "website": "https:\/\/redis.io\/docs\/latest\/develop\/tools\/cli\/", "source_url": "https:\/\/redis.io\/docs\/latest\/operate\/rs\/7.4\/references\/cli-utilities\/redis-cli\/", "stars": 73330, "language": "C", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "redis", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Redis" }, { "slug": "strapi", "name": "Strapi CLI", "description": "Official Strapi CLI for creating projects, running Strapi apps, scaffolding API and content-type code, and moving data between environments.", "long_description": "Strapi CLI is the command surface around Strapi CMS projects for project creation, local development, code generation, data movement, and Cloud deployment. It is mainly useful to developers and operators working inside a Strapi codebase rather than editors managing content records directly from the shell.\n\n## What It Enables\n- Create a new Strapi project and run local `develop`, `build`, `start`, `console`, and type-generation workflows.\n- Scaffold APIs, content types, controllers, services, policies, middlewares, migrations, and inspect registered content types, routes, hooks, or services.\n- Export, import, and transfer Strapi data and configuration, generate OpenAPI specs, manage admin users, and deploy linked projects to Strapi Cloud.\n\n## Agent Fit\n- Works best when an agent is already in a Strapi project and needs to inspect the app, generate files, or operate environments from the shell.\n- Structured output exists but is limited: `configuration:dump` emits JSON and `openapi generate` writes JSON, while most list, report, and Cloud commands print human-oriented text or tables.\n- Automation is possible with flags like `--non-interactive` and `--force`, but browser login, token prompts, key prompts, and destructive confirmations limit unattended use.\n\n## Caveats\n- Most commands are project-local and often boot or inspect the app itself, so this is not a general remote content-management CLI; Strapi's HTTP APIs are usually the better surface for record-level work.\n- Import and transfer can overwrite or delete existing data, and the docs mark OpenAPI generation as experimental.", "category": "http-apis", "install": "npx create-strapi@latest", "github": "https:\/\/github.com\/strapi\/strapi", "website": "https:\/\/docs.strapi.io\/cms\/cli", "source_url": "https:\/\/docs.strapi.io\/cms\/cli", "stars": 71510, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Strapi" }, { "slug": "caddy", "name": "Caddy", "description": "Web server and reverse proxy CLI for running, validating, and reloading Caddy configs with automatic HTTPS.", "long_description": "Caddy is a web server and reverse proxy CLI built around a long-running server process plus commands for adapting, validating, and reloading its native JSON config. It is useful when you want one tool to serve static sites, proxy upstream apps, and manage HTTPS certificates without bolting together separate components.\n\n## What It Enables\n- Run local or production web servers, reverse proxies, and static file servers from config files or purpose-built subcommands like `file-server` and `reverse-proxy`.\n- Adapt Caddyfiles and other supported config formats into native JSON, validate them before deploy, then reload a running instance through the admin API.\n- Inspect installed modules, export or import storage assets such as certificates, and manage local trust for Caddy's internal CA during HTTPS workflows.\n\n## Agent Fit\n- Commands map well to inspect, change, and verify loops: `adapt`, `validate`, `reload`, `stop`, `list-modules`, and trust commands are direct subcommands with clear exit behavior.\n- JSON support is useful but narrow: `adapt` emits native JSON config and `list-modules --json` gives machine-readable module metadata, while most operational output is still logs and plain text.\n- Best when a project already has Caddy config conventions or deployment scripts; agents become much safer once addresses, cert policy, and admin API access are captured in skills.\n\n## Caveats\n- Many actions target a running admin API or privileged ports, so unattended use depends on local permissions, reachable listeners, and careful config review before reloads.\n- Caddy is primarily a server and proxy runtime CLI, not a general service-management surface; most automation value is on hosts where you control the web-serving stack.", "category": "networking", "install": "brew install caddy", "github": "https:\/\/github.com\/caddyserver\/caddy", "website": "https:\/\/caddyserver.com\/docs\/command-line", "source_url": null, "stars": 70664, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "ZeroSSL" }, { "slug": "swift", "name": "Swift toolchain", "description": "Swift toolchain CLI for compiling code and building, running, testing, or inspecting Swift packages.", "long_description": "Swift is the command-line toolchain for compiling Swift code and driving package-based workflows. It covers compiler invocations directly and, through bundled package-manager subcommands, local package creation, builds, tests, runs, and dependency resolution.\n\n## What It Enables\n- Compile Swift sources into executables, libraries, or modules, and inspect driver behavior or target information when integrating Swift into custom build flows.\n- Initialize, build, run, test, resolve, update, and edit Swift packages from a project directory without leaving the shell.\n- Inspect package manifests and dependency graphs with JSON-producing subcommands for automation, validation, or follow-up tooling.\n\n## Agent Fit\n- Works well in local project loops because core flows like `swift build`, `swift test`, and `swift package ...` are non-interactive and scriptable.\n- Structured output exists but is uneven: the compiler driver has documented parseable JSON output, and package inspection commands expose JSON, while many other commands remain text-first.\n- Best fit for agents operating inside a checked-out Swift codebase rather than managing remote services or long-lived system state.\n\n## Caveats\n- Installing or switching toolchains is platform-specific and heavier than a single-binary CLI.\n- The full `swift` command surface spans multiple official repos, so this repo is only part of the implementation story for package-oriented subcommands.", "category": "package-managers", "install": "curl -O https:\/\/download.swift.org\/swiftly\/darwin\/swiftly.pkg && installer -pkg swiftly.pkg -target CurrentUserHomeDirectory && ~\/.swiftly\/bin\/swiftly init --quiet-shell-followup && . \"${SWIFTLY_HOME_DIR:-$HOME\/.swiftly}\/env.sh\" && hash -r", "github": "https:\/\/github.com\/swiftlang\/swift", "website": "https:\/\/www.swift.org\/documentation\/", "source_url": "https:\/\/www.swift.org\/documentation\/", "stars": 69860, "language": "C++", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Swift" }, { "slug": "act", "name": "act", "description": "Run GitHub Actions workflows locally in Docker to test jobs, event payloads, and CI changes before pushing.", "long_description": "act is a local runner for GitHub Actions workflows. It reads `.github\/workflows`, plans jobs for an event or selected job, and executes them in Docker so you can test CI behavior before pushing.\n\n## What It Enables\n- Run workflow jobs locally against a chosen event payload or job ID, with local secrets, vars, env files, matrix filters, and repository overrides.\n- List workflows, inspect stage ordering as a graph, validate workflow definitions, and dry-run execution paths before spending CI time on GitHub-hosted runners.\n- Iterate faster on workflows and custom actions with local caches, artifact or cache servers, and `--watch` reruns when files change.\n\n## Agent Fit\n- Once Docker access and runner image mappings are configured, commands are mostly non-interactive and fit inspect-change-verify loops around CI debugging.\n- Structured output is limited but real: `--json` emits JSON logs and `--list-options` returns a JSON description of supported flags.\n- Best for agents already operating inside a repo with GitHub Actions; it is less useful as a general GitHub control plane because behavior depends on local workflow fidelity and containerized runner support.\n\n## Caveats\n- Execution depends on Docker-compatible containers and suitable runner images, and the docs explicitly note that `act` is not completely compatible with GitHub runners.\n- First run can prompt for a default image selection unless `.actrc` or explicit `-P` or `--platform` mappings are already in place.", "category": "dev-tools", "install": "brew install act", "github": "https:\/\/github.com\/nektos\/act", "website": "https:\/\/nektosact.com\/", "source_url": null, "stars": 69196, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "githubactions", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "ansible", "name": "Ansible", "description": "Infrastructure automation CLI suite for remote execution, inventory inspection, and playbook-driven configuration changes.", "long_description": "Ansible is an infrastructure automation CLI suite for defining and applying changes across groups of machines from a control node. It combines ad hoc execution, playbook runs, inventory inspection, config introspection, secret handling, and collection management in one toolchain.\n\n## What It Enables\n- Run one-off modules or repeatable playbooks across inventory-defined hosts to install packages, manage files and services, gather facts, or orchestrate multi-host changes.\n- Inspect inventories, config state, plugin docs, and installed Galaxy collections before changing anything, then use those results in follow-up automation.\n- Encrypt secrets with `ansible-vault` and use `ansible-pull` when you want nodes to fetch and apply playbooks themselves.\n\n## Agent Fit\n- Useful for agents because it exposes real inspect, change, and verify loops against remote systems from non-TUI commands.\n- Machine-readable output is uneven but real: `ansible-doc --json`, `ansible-config --format json`, `ansible-inventory --list`, and `ansible-galaxy collection list --format json` support parsing, while playbook and ad hoc runs default to callback-oriented human output.\n- Best when inventory, credentials, and playbooks already exist; agents can operate effectively once those environment conventions are captured in skills.\n\n## Caveats\n- Real work depends on inventory, credentials, reachable managed nodes, and often privilege-escalation setup; without that, the CLI is mostly a local control layer.\n- Structured output is inconsistent across the suite, so agents often need callback configuration or wrapper steps when parsing playbook or ad hoc results.", "category": "cloud", "install": "pipx install --include-deps ansible", "github": "https:\/\/github.com\/ansible\/ansible", "website": "https:\/\/docs.ansible.com\/ansible\/latest\/", "source_url": "https:\/\/docs.ansible.com\/ansible\/latest\/cli\/ansible.html", "stars": 68236, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Ansible" }, { "slug": "codex-cli", "name": "Codex CLI", "description": "OpenAI's lightweight terminal coding agent for editing, running tasks, and agentic development loops.", "long_description": "Codex CLI is OpenAI's terminal coding agent for working inside a local repository, either through a fullscreen interactive session or headless runs. It covers code editing, command execution, review, session management, and integration surfaces for other clients.\n\n## What It Enables\n- Work through coding tasks in a local repo, with the agent reading files, proposing patches, running shell commands, and resuming or forking prior sessions.\n- Run one-shot or unattended agent tasks with `codex exec` and `codex review`, including structured final-output schemas and JSONL event streams for follow-up tooling.\n- Manage MCP connections for Codex or expose Codex itself over JSON-RPC so editors or other clients can drive the agent outside the TUI.\n\n## Agent Fit\n- Useful when you want a higher-level coding primitive rather than a narrow service CLI, especially for repo changes, validation loops, and review passes.\n- Non-interactive subcommands, JSONL events, and explicit sandbox or approval flags make it scriptable enough for agent workflows, even though the default experience is conversational.\n- Best fit when paired with project skills and local policy defaults; it can also connect to MCP-based setups when that integration model is needed.\n\n## Caveats\n- A lot of the product value still depends on model-driven behavior rather than deterministic command semantics, so outputs are less predictable than service CLIs with fixed schemas.\n- Authentication, approvals, sandbox policy, and some setup flows can require interactive choices before unattended use is reliable.", "category": "agent-harnesses", "install": "npm install -g @openai\/codex", "github": "https:\/\/github.com\/openai\/codex", "website": "https:\/\/github.com\/openai\/codex", "source_url": "https:\/\/github.com\/openai\/codex", "stars": 63681, "language": "Rust", "has_mcp": true, "has_skill": true, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": true, "source_type": "github", "vendor_name": "OpenAI" }, { "slug": "prometheus", "name": "Prometheus", "description": "Monitoring server and companion CLI for validating Prometheus configs and rules, querying servers, and inspecting TSDB data.", "long_description": "Prometheus is the canonical open source monitoring server, with a companion `promtool` CLI for validating configs, testing rules, querying servers, and inspecting TSDB data. For `clis.dev`, the durable CLI value comes mostly from those operational workflows rather than from daemon startup alone.\n\n## What It Enables\n- Run Prometheus in server or agent mode with flags for storage, web and API exposure, feature flags, and reload behavior.\n- Validate Prometheus configs, web configs, and rule files, and unit test alerting or recording rules before rollout.\n- Query a live Prometheus, inspect service-discovery results or TSDB contents, fetch debug bundles, and push sample metrics for testing.\n\n## Agent Fit\n- Best in inspect\/change\/verify loops around Prometheus operations: linting, rule tests, ad hoc queries, and TSDB inspection are non-interactive and scriptable.\n- The companion `promtool` supports structured output for queries and TSDB dumps, and the server can emit JSON logs for downstream parsing.\n- Much of the real workflow still depends on a running Prometheus instance, config files, and HTTP endpoints, so it is less self-contained than remote-service CLIs.\n\n## Caveats\n- Official docs recommend released binaries from the download page; `go install` is source-oriented and comes with web-asset caveats.\n- The `prometheus` binary is primarily a long-running daemon, so many useful CLI commands either target an existing server or operate on local TSDB data.", "category": "system-monitoring", "install": null, "github": "https:\/\/github.com\/prometheus\/prometheus", "website": "https:\/\/prometheus.io\/docs\/prometheus\/latest\/command-line\/prometheus\/", "source_url": "https:\/\/prometheus.io\/docs\/prometheus\/latest\/command-line\/prometheus\/", "stars": 63098, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "promtool", "name": "promtool", "description": "Prometheus utility CLI for validating configs and rules, querying servers, linting metrics, and inspecting TSDB data.", "long_description": "`promtool` is Prometheus's utility CLI for checking, querying, testing, and debugging monitoring setups from the shell. It sits around a Prometheus deployment rather than replacing the server, giving you direct commands for validation, inspection, and TSDB-level maintenance tasks.\n\n## What It Enables\n- Validate Prometheus config files, rule files, web config, and discovered targets before rollout or in CI.\n- Query a Prometheus server, check health and readiness, inspect label values or series, and fetch debug data from the terminal.\n- Lint scraped metrics, unit test alerting or recording rules, dump or analyze TSDB blocks, and backfill blocks from OpenMetrics or recording rules.\n\n## Agent Fit\n- `promtool query` can emit JSON, and most commands use stable flags, stdout, and exit codes that fit unattended validation and follow-up parsing.\n- It works well in inspect, change, verify loops around Prometheus because agents can check configs, run rule tests, query live data, and inspect TSDB state without opening the UI.\n- Coverage is narrower than a general infrastructure CLI: many commands are read-only diagnostics, and server-facing actions depend on reachable Prometheus endpoints or local TSDB files.\n\n## Caveats\n- Some useful surfaces are explicitly experimental, including `promql` editing and parts of the TSDB tooling.\n- The recommended install path in the repo is released binaries from prometheus.io, so the current `go install` entry is more of a build path than the main end-user install flow.", "category": "system-monitoring", "install": "go install github.com\/prometheus\/prometheus\/cmd\/...", "github": "https:\/\/github.com\/prometheus\/prometheus", "website": "https:\/\/prometheus.io\/docs\/prometheus\/latest\/command-line\/promtool\/", "source_url": "https:\/\/prometheus.io\/docs\/prometheus\/latest\/command-line\/promtool\/", "stars": 63098, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Prometheus" }, { "slug": "ripgrep", "name": "ripgrep", "description": "Recursive regex search CLI with ignore-file awareness, glob and type filters, and optional JSON Lines output.", "long_description": "ripgrep is a recursive text search CLI for code and other file trees. It combines regex search with ignore-file awareness, glob and file-type filters, and a structured output mode for downstream tooling.\n\n## What It Enables\n- Search large repos or directories without manually excluding ignored, hidden, or binary content unless you explicitly want to.\n- Narrow searches by glob, file type, encoding, compressed file content, or a custom preprocessor when plain recursive grep is too blunt.\n- Feed match locations, context, and per-file summaries into scripts or agents through JSON Lines output for follow-up edits, triage, or reporting.\n\n## Agent Fit\n- `--json` emits machine-readable begin, match, context, end, and summary messages, including offsets and safe handling for non-UTF-8 paths or bytes.\n- Non-interactive flags, predictable search behavior, and path or type filtering make it a strong primitive for CI checks, codebase audits, and search-then-edit loops.\n- It is inspection-first: ripgrep does not modify files, and some alternate output modes such as file lists or counts cannot be combined with JSON.\n\n## Caveats\n- Default filtering can hide expected matches until you add flags like `-u`, `--hidden`, `--text`, or `--follow`.\n- Matching is line-oriented by default; multiline or PCRE2-heavy searches are opt-in and can cost performance.", "category": "file-management", "install": "brew install ripgrep", "github": "https:\/\/github.com\/BurntSushi\/ripgrep", "website": null, "source_url": null, "stars": 60655, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "cline", "name": "Cline", "description": "Terminal coding agent CLI for local repo tasks, file edits, shell commands, and browser-based debugging.", "long_description": "Cline is a terminal coding agent for working inside a local project, with both a full-screen interactive UI and headless execution for scripts. It can inspect code, edit files, run shell commands, and use a browser while keeping approvals and configuration in the terminal.\n\n## What It Enables\n- Run repo-aware coding tasks that read files, apply edits, execute tests or build commands, and iterate until a task completes.\n- Pipe diffs, logs, or file contents into headless runs for reviews, summaries, release notes, and automated fix loops.\n- Reuse the agent in editors like JetBrains, Neovim, or Zed through `--acp`, so editor integrations can call the same terminal-side agent runtime.\n\n## Agent Fit\n- `--json`, piped stdin, task resume IDs, and automatic headless mode give it a real shell-friendly automation surface.\n- Most output and control flow are still centered on an agent conversation with approvals, so it is less deterministic than narrow service CLIs with stable subcommands.\n- Fits best as a higher-level coding primitive when a skill or wrapper pins the working directory, approval mode, provider setup, and allowed commands. ACP mode and configurable MCP servers also let teams plug it into editor-hosted workflows when needed.\n\n## Caveats\n- Real use depends on configuring a model provider or account, and autonomous `-y` runs are safest on disposable branches because the tool can edit files and execute commands.\n- The repo is a combined VS Code extension and CLI monorepo, so the root README is editor-heavy and the CLI-specific behavior lives under `cli\/` and `docs\/cline-cli\/`.", "category": "agent-harnesses", "install": "npm install -g cline", "github": "https:\/\/github.com\/cline\/cline", "website": "https:\/\/docs.cline.bot\/cline-cli\/getting-started", "source_url": "https:\/\/cline.bot", "stars": 58762, "language": "TypeScript", "has_mcp": true, "has_skill": true, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": true, "source_type": "github", "vendor_name": "Cline" }, { "slug": "mkcert", "name": "mkcert", "description": "Generate and install locally trusted development TLS certificates for localhost, custom domains, and IPs.", "long_description": "mkcert creates a local certificate authority and issues locally trusted TLS certificates for development hosts, localhost names, and other local endpoints. It is built to remove the manual trust-store and OpenSSL ceremony that usually makes local HTTPS setup tedious.\n\n## What It Enables\n- Generate trusted certificate and key files for localhost, custom domains, wildcards, IP addresses, email identities, or URI SANs during local development.\n- Install or uninstall the local CA in system, NSS browser, and Java trust stores so local apps and browsers accept those certificates without warnings.\n- Issue client-auth, CSR-based, ECDSA, or PKCS#12 certificates and control CA location or output paths for repeatable dev-environment setup scripts.\n\n## Agent Fit\n- The command surface is small and flag-driven, so agents can reliably run `-install`, `-uninstall`, `-CAROOT`, or certificate issuance commands inside local bootstrap workflows.\n- Output is plain text only, which is fine for file-producing setup steps but weaker for parsing or state inspection than CLIs with real JSON output.\n- Best used as a local development primitive around app setup and HTTPS verification, not as a general certificate-management interface for remote infrastructure.\n\n## Caveats\n- `-install` changes local trust stores and may require `sudo`, `certutil`, or `keytool` depending on platform and browser setup.\n- The generated `rootCA-key.pem` is sensitive and the project is explicitly intended for development rather than production certificate workflows.", "category": "security", "install": "brew install mkcert", "github": "https:\/\/github.com\/FiloSottile\/mkcert", "website": "https:\/\/mkcert.dev", "source_url": null, "stars": 58278, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "ffmpeg", "name": "ffmpeg", "description": "Media processing CLI for recording, transcoding, filtering, muxing, and streaming audio or video.", "long_description": "FFmpeg is the core command-line tool in the FFmpeg project for turning media files, streams, and capture devices into new media outputs. It covers one-off conversions, complex filter graphs, remuxing, live ingest, and scripted media pipelines.\n\n## What It Enables\n- Transcode or remux audio, video, subtitle, and attachment streams between many container and codec combinations.\n- Capture from files, pipes, network streams, or recording devices, then filter, trim, resize, mix, or package the result for delivery.\n- Build repeatable media workflows in shell scripts or CI, including batch conversions, live stream processing, and pipe-based handoffs to other tools.\n\n## Agent Fit\n- Its command surface is large but highly scriptable: flags, stream mapping, pipes, and exit codes make it practical for unattended media jobs once the command is known.\n- Machine-readable support exists, but it is uneven: `-progress` emits key-value status data and execution graphs can be printed as JSON, while deeper media inspection is usually better delegated to `ffprobe`.\n- Works well as an action primitive when a skill can encode project-specific presets, codec constraints, and filtergraph patterns for recurring workflows.\n\n## Caveats\n- Feature availability depends on how the binary was built, since codecs, hardware acceleration, and external-library support vary by package or source build.\n- The option surface is broad and stdin interaction is enabled by default, so unattended runs should usually be explicit about flags such as `-nostdin`, mappings, codecs, and overwrite behavior.", "category": "media", "install": null, "github": "https:\/\/github.com\/FFmpeg\/FFmpeg", "website": "https:\/\/ffmpeg.org\/ffmpeg.html", "source_url": null, "stars": 57669, "language": "C", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "ffmpeg", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "rclone", "name": "rclone", "description": "Cloud storage CLI for copying, syncing, mounting, serving, and inspecting files across local and 70+ backends.", "long_description": "rclone is a general-purpose file transfer and sync CLI for cloud storage, network protocols, and local filesystems. It covers one-off copies, ongoing sync, integrity checks, virtual remotes like encryption, and exposing remote data as mounts or network services.\n\n## What It Enables\n- Copy, sync, move, and verify files between local paths and cloud or protocol-backed remotes without writing provider-specific scripts.\n- List remote objects in JSON, inspect usage or config state, and compare source and destination trees before making changes.\n- Mount remotes as local filesystems or serve them over HTTP, WebDAV, FTP, SFTP, or DLNA when a direct file API is not enough.\n\n## Agent Fit\n- Commands like `copy`, `sync`, `check`, `lsjson`, `config dump`, and `config providers` work cleanly in shell automation, with dry-run protection and stable flags.\n- Machine-readable output exists for specific surfaces, especially `lsjson`, config JSON commands, and the RC API, but not every transfer command emits structured JSON.\n- It fits inspect\/change\/verify loops well for backup, migration, and cross-cloud workflows; setup is the main friction because many remotes need credentials or OAuth.\n\n## Caveats\n- Remote setup can involve interactive config flows, browser-based OAuth, or backend-specific credentials before unattended use is practical.\n- Long-running `mount` or `serve` workflows behave more like managed services than one-shot commands and need extra care around permissions, caching, and lifecycle.", "category": "cloud", "install": "brew install rclone", "github": "https:\/\/github.com\/rclone\/rclone", "website": "https:\/\/rclone.org", "source_url": null, "stars": 55908, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "gitea", "name": "Gitea CLI", "description": "Gitea CLI for issues, pull requests, releases, actions, webhooks, and API calls.", "long_description": "tea is Gitea's official CLI for working with one or more Gitea instances from the shell. It covers day-to-day collaboration and service operations around repositories, issues, pull requests, releases, actions, webhooks, notifications, and raw API access.\n\n## What It Enables\n- List, create, edit, close, and comment on issues or pull requests, then check out, review, approve, reject, or merge PRs from a local clone.\n- Inspect and update repository state such as releases, labels, milestones, branches, tracked time, action secrets or variables, notifications, and webhooks.\n- Call arbitrary Gitea REST endpoints with `tea api` when a built-in subcommand does not cover the workflow you need.\n\n## Agent Fit\n- Real machine-readable output is available through `--output json` and related formats across many list commands, and issue or pull detail views can also emit JSON.\n- Login profiles, repo-aware defaults, and a raw `api` escape hatch make it practical for inspect\/change\/verify loops across one or many Gitea instances.\n- Some paths still prompt interactively for auth, comments, editors, or confirmations, so unattended runs should pass flags explicitly and avoid prompt-driven flows.\n\n## Caveats\n- Best results assume a local git checkout with correctly configured remotes; commands like PR checkout and repo inference depend on local git context.\n- Authentication options vary by deployment. Token login is the safest baseline, while OAuth or SSH-based flows depend on instance configuration.", "category": "github", "install": "brew install tea", "github": "https:\/\/github.com\/go-gitea\/gitea", "website": "https:\/\/gitea.com\/gitea\/tea", "source_url": null, "stars": 54172, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "gitea", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Gitea" }, { "slug": "dive", "name": "dive", "description": "Inspect Docker and OCI image layers, file changes, and wasted space to debug and optimize container images.", "long_description": "dive is a container image inspection CLI centered on layer-by-layer exploration. It opens a fullscreen TUI by default to show file changes, image efficiency, and wasted space, and can also run headless for CI checks or JSON export.\n\n## What It Enables\n- Open an image from Docker, Podman, or a Docker archive and inspect each layer's contents, build commands, and file-level changes.\n- Find duplicated or leftover files that bloat an image, with efficiency and wasted-byte estimates that help guide Dockerfile cleanup.\n- Build an image and jump straight into analysis, or gate CI on efficiency and wasted-space thresholds to catch regressions.\n\n## Agent Fit\n- The default experience is a fullscreen TUI, so the strongest agent use is assisted inspection rather than pure headless automation.\n- There is a real non-interactive path: `--json` writes structured layer and inefficiency data to a file, and `--ci` or `CI=true` returns pass or fail exit codes for scripted checks.\n- Fits container build workflows well when an agent needs to inspect image composition after a build, but it is narrower than general-purpose image build or registry CLIs.\n\n## Caveats\n- It needs access to a local image source such as Docker, Podman on Linux, or a Docker archive; it is not a remote registry inspection CLI by itself.\n- The README still labels the project beta quality, and its image-efficiency score is an estimate rather than a strict guarantee of image quality.", "category": "containers", "install": "brew install dive", "github": "https:\/\/github.com\/wagoodman\/dive", "website": null, "source_url": null, "stars": 53505, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "docker", "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "etcdctl", "name": "etcdctl", "description": "CLI for reading and writing etcd keys, checking cluster health, and managing members, auth, leases, and snapshots.", "long_description": "`etcdctl` is the upstream CLI for interacting with and administering etcd v3 clusters over the network. It covers both application-facing key-value operations and operator tasks such as member management, authentication, health checks, snapshots, and diagnosis.\n\n## What It Enables\n- Read, write, delete, and transactionally update keys, query ranges and revisions, watch changes, and manage leases from the shell.\n- Inspect endpoint health, status, and hash consistency, manage cluster membership, take backend snapshots, and run diagnosis or performance checks.\n- Enable authentication, manage users and roles, and use built-in distributed lock or leader-election helpers backed by etcd.\n\n## Agent Fit\n- Most commands are direct subcommands with flags and exit codes against a live cluster, so they fit inspect, change, and verify loops once endpoints and TLS or auth settings are known.\n- Machine-readable output is real through global `--write-out` modes including JSON, fields, protobuf, and table, which makes endpoint, member, and many RPC-backed responses script-friendly.\n- Automation fit is mixed by command: many paths are non-interactive, but watches, lease keep-alives, locks, elections, and interactive `txn` sessions are streaming or session-oriented, and upstream only guarantees compatibility for the default `simple` output format.\n\n## Caveats\n- Useful automation requires a reachable etcd cluster plus the right endpoint, TLS, and authentication configuration.\n- JSON output exists, but the v3 README explicitly says backward compatibility is only guaranteed for normal commands in `simple` format.", "category": "containers", "install": "brew install etcd", "github": "https:\/\/github.com\/etcd-io\/etcd", "website": "https:\/\/etcd.io\/docs\/latest\/dev-guide\/interacting_v3\/", "source_url": "https:\/\/etcd.io\/docs\/latest\/dev-guide\/interacting_v3\/", "stars": 51630, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "etcd" }, { "slug": "cypress", "name": "Cypress", "description": "Browser testing CLI for running and debugging Cypress end-to-end and component tests against web apps.", "long_description": "Cypress is a browser testing CLI for running end-to-end and component tests against web apps. It can launch the interactive Cypress app for local debugging, run suites headlessly in CI, and expose a Node module API for programmatic test execution.\n\n## What It Enables\n- Run end-to-end or component test suites in Electron or installed browsers, scoped by spec, project path, config overrides, and env variables.\n- Open the interactive Cypress app to select projects, inspect failing tests, and debug browser-driven test runs locally.\n- Record runs to Cypress Cloud and feed custom reporters or module API results into CI workflows, including screenshots and video metadata.\n\n## Agent Fit\n- Useful when an agent already has a Cypress project and needs a direct browser-verification step after changing a web app.\n- The shell surface is scriptable for `run`, `verify`, `cache`, and `info`, with stable flags for specs, browsers, config, env, and reporters.\n- Structured results are stronger through the Node module API than the CLI itself; shell output is mostly human-readable and the richest debugging workflow lives in `cypress open`.\n\n## Caveats\n- Setup is heavier than a single-binary CLI because the npm package installs and verifies a separate Cypress executable.\n- A lot of the product's day-to-day value is still GUI-first, so unattended shell usage is best for executing existing tests rather than authoring or deep debugging.", "category": "testing", "install": "npm install --save-dev cypress", "github": "https:\/\/github.com\/cypress-io\/cypress", "website": "https:\/\/on.cypress.io\/cli", "source_url": null, "stars": 49596, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Cypress" }, { "slug": "terraform", "name": "Terraform", "description": "Infrastructure-as-code CLI for planning, applying, and inspecting Terraform-managed infrastructure, state, and outputs.", "long_description": "Terraform is HashiCorp's CLI for planning, applying, and inspecting infrastructure changes defined in HCL. It covers the full local workflow around state, outputs, providers, modules, imports, validation, and remote backend operations.\n\n## What It Enables\n- Preview infrastructure changes, save execution plans, and apply or destroy resources across supported providers and backends.\n- Inspect current state, output values, module dependencies, provider schemas, and version data when debugging or generating follow-up automation.\n- Format, validate, import, and test Terraform configurations before shipping them through CI or agent-managed infrastructure workflows.\n\n## Agent Fit\n- JSON views across many commands, plus plain stdout, stderr, and exit codes, make Terraform workable in shell-driven inspect\/change\/verify loops.\n- Saved plan files, `-detailed-exitcode`, `-input=false`, and `-auto-approve` let agents separate review from execution instead of relying on prompts.\n- Best fit when an agent is operating in a prepared workspace with initialized providers, backend access, and clear approval rules for destructive changes.\n\n## Caveats\n- Real runs depend on provider credentials, initialized plugins, and reachable remote backends, so many failures come from the target systems rather than the CLI itself.\n- Some machine-readable modes can expose sensitive values, and unattended applies still need explicit approval settings or precomputed plan files.", "category": "cloud", "install": "brew tap hashicorp\/tap && brew install hashicorp\/tap\/terraform", "github": "https:\/\/github.com\/hashicorp\/terraform", "website": "https:\/\/developer.hashicorp.com\/terraform\/cli", "source_url": null, "stars": 47906, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "terraform", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "HashiCorp" }, { "slug": "expo-cli", "name": "Expo CLI", "description": "Expo CLI for starting Expo and React Native dev servers, generating native projects, running local iOS or Android builds, and inspecting project config.", "long_description": "Expo CLI is the command surface for working on Expo and React Native apps from a project directory. It starts the dev server, generates native iOS and Android projects, runs local builds, and inspects or syncs Expo-specific project state.\n\n## What It Enables\n- Start an Expo dev server, open Android, iOS, or web targets, and use the terminal UI to reload apps, open tools, or switch between Expo Go and development builds.\n- Generate or regenerate native `ios\/` and `android\/` projects from app config with `expo prebuild`, then compile and install local builds with `run:ios` or `run:android`.\n- Inspect resolved Expo config and check or fix dependency versions that match the project's Expo and React Native SDK.\n\n## Agent Fit\n- Useful when an agent is already inside an Expo project and needs direct build, config, or dependency commands instead of a cloud service wrapper.\n- Non-interactive flags and exit codes make `prebuild`, `run:*`, and dependency checks scriptable, and `expo config --json` plus `expo install --check --json` give it a real machine-readable surface.\n- The main dev workflow still leans on `expo start`'s interactive terminal UI and local toolchains like Xcode, Android Studio, simulators, and device setup. It can also connect to Expo's MCP path during `expo start`, but that integration is experimental and secondary to the direct CLI workflow.\n\n## Caveats\n- Expo CLI is bundled with the `expo` package, so install and discovery are easy to misread if you are expecting a standalone `expo-cli` package.\n- Local iOS and Android build commands depend on native tooling and, for iOS, a Mac with Xcode and simulator or device access.", "category": "dev-tools", "install": "yarn add expo", "github": "https:\/\/github.com\/expo\/expo", "website": "https:\/\/docs.expo.dev\/more\/expo-cli\/", "source_url": "https:\/\/docs.expo.dev\/more\/expo-cli\/", "stars": 47782, "language": "TypeScript", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Expo" }, { "slug": "brew", "name": "Homebrew", "description": "Package manager CLI for installing, upgrading, and querying formulae, casks, taps, and Brewfile dependencies on macOS and Linux.", "long_description": "Homebrew is a package manager CLI for macOS and Linux that installs formulae, casks, taps, and Brewfile-defined dependency sets. It also exposes package metadata, service management, and environment helpers for scripting local machine setup and maintenance.\n\n## What It Enables\n- Install, upgrade, pin, uninstall, and clean up command-line tools and GUI apps from formulae and casks on macOS or Linux.\n- Search packages, inspect formula or tap metadata, and check outdated or installed state before changing a machine.\n- Capture machine setup in a `Brewfile`, enforce it with `brew bundle`, and manage packaged background services with `brew services`.\n\n## Agent Fit\n- Core commands are scriptable and fit inspect-change-verify loops for local machine bootstrap and maintenance.\n- Structured output is real but partial: `brew info`, `brew outdated`, `brew tap-info`, and `brew services ... --json` support JSON, while many install and search flows still emit plain text.\n- Built-in `brew mcp-server` exists for teams that prefer that integration model.\n\n## Caveats\n- Install, upgrade, and uninstall commands change the local machine and can fetch or execute third-party build steps, so unattended use needs guardrails.\n- Some flows still prompt or depend on local OS state, permissions, or service managers; unattended installs may need `NONINTERACTIVE=1`.", "category": "package-managers", "install": "\/bin\/bash -c \"$(curl -fsSL https:\/\/raw.githubusercontent.com\/Homebrew\/install\/HEAD\/install.sh)\"", "github": "https:\/\/github.com\/Homebrew\/brew", "website": "https:\/\/brew.sh", "source_url": "https:\/\/brew.sh", "stars": 46905, "language": "Ruby", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "clickhouse", "name": "ClickHouse CLI", "description": "Official ClickHouse CLI for running SQL against servers, loading data, and querying files locally.", "long_description": "ClickHouse ships a native SQL client and a local query utility in the same toolchain. It gives you a direct command surface for querying ClickHouse servers or using ClickHouse SQL on local and remote files without standing up a cluster.\n\n## What It Enables\n- Run ad hoc or scripted SQL against ClickHouse servers with `--query`, stdin, and URI or flag-based connection options.\n- Insert data from files or pipelines, parameterize queries from the command line, and export results in formats such as CSV or JSON.\n- Use `clickhouse-local` to query local files or S3 objects, infer schemas, and convert data between formats without starting a server.\n\n## Agent Fit\n- Batch mode, stdin\/stdout piping, parameterized queries, and explicit flags make it easy to wrap in shell or CI loops.\n- Machine-readable output is available, but you need to request it with `--format`, `--output-format`, or SQL `FORMAT` clauses because interactive defaults are human-oriented.\n- Best fit for agents already operating in a ClickHouse environment or data pipeline; most failures come from credentials, target state, or SQL errors rather than the CLI surface.\n\n## Caveats\n- Server workflows require reachable ClickHouse instances and credentials; if you omit a password, the client will prompt interactively.\n- `clickhouse-local` is positioned for ad hoc file processing and testing, not as a production serving layer.", "category": "databases", "install": "curl https:\/\/clickhouse.com\/ | sh", "github": "https:\/\/github.com\/ClickHouse\/ClickHouse", "website": "https:\/\/clickhouse.com\/docs\/interfaces\/cli", "source_url": "https:\/\/clickhouse.com\/docs\/interfaces\/cli", "stars": 46238, "language": "C++", "has_mcp": false, "has_skill": true, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "ClickHouse" }, { "slug": "prisma", "name": "Prisma CLI", "description": "Prisma ORM CLI for schema setup, client generation, database introspection, migrations, and local database workflows.", "long_description": "Prisma CLI is the command surface around Prisma ORM for setting up schemas, generating client code, introspecting existing databases, and running migration workflows in application projects. It also includes local Prisma Postgres development helpers and Prisma Studio launch commands.\n\n## What It Enables\n- Initialize a Prisma project, start local Prisma Postgres for development, and generate or regenerate Prisma Client artifacts from schema changes.\n- Introspect an existing database into `schema.prisma`, validate or format schema files, and compare schema states before applying changes.\n- Create, apply, deploy, resolve, reset, and inspect migrations, or execute SQL and seed flows against the configured datasource.\n\n## Agent Fit\n- Best when an agent is already inside a Prisma codebase and needs to inspect schema files, generate client output, or run migration and introspection steps against a known database.\n- Machine-readable output exists but is narrow: `prisma version --json` and `prisma platform status --json` are structured, while most high-value ORM commands emit human-oriented text and warnings.\n- Non-interactive commands like `db pull`, `generate`, `validate`, `migrate status`, and `migrate diff` compose well in scripts; `migrate dev`, `db push`, `studio`, and destructive reset flows are less suitable for unattended use, though `prisma mcp` is available when teams want that integration model.\n\n## Caveats\n- Most commands depend on a valid `prisma.config.ts` and reachable database URL; the README notes Prisma does not auto-load `.env` files for that config.\n- Several workflows are explicitly development-only or open a browser UI, and commands like `migrate reset` or `db push --force-reset` can drop data.", "category": "databases", "install": "npm install prisma --save-dev", "github": "https:\/\/github.com\/prisma\/prisma", "website": "https:\/\/docs.prisma.io\/docs\/cli", "source_url": "https:\/\/www.prisma.io", "stars": 45474, "language": "TypeScript", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Prisma" }, { "slug": "pm2", "name": "PM2", "description": "Process manager CLI for running, reloading, scaling, and inspecting long-lived Node.js, Bun, and other app processes.", "long_description": "PM2 is a daemon-backed process manager for keeping long-running app processes alive on a server, restarting them after failure, and reloading or scaling them without hand-rolling service scripts. It is mainly a host-level control layer for Node.js and Bun apps, but it can also supervise other interpreters and binaries.\n\n## What It Enables\n- Start apps from a script or ecosystem file, keep them running, and restart or reload them after code or config changes.\n- Scale Node.js or Bun services across CPU cores, inspect process state, and stream or query logs from one CLI.\n- Persist process state across reboots with generated startup scripts or run apps under `pm2-runtime` inside containers.\n\n## Agent Fit\n- `jlist` returns raw process data as JSON and `logs --json` emits structured log and process-event lines, so agents can inspect host state and parse follow-up actions without screen scraping.\n- The command set is broad for host-level operations: start, stop, reload, scale, describe, save, startup, and runtime container entrypoints all work cleanly in shell scripts once PM2 is installed on the target machine.\n- Fit is narrower for remote-service workflows because PM2 manages local daemon state under `~\/.pm2`, and commands like `monit`, `dashboard`, or `startup` are TTY-oriented or privilege-gated.\n\n## Caveats\n- Commands act on the local machine's PM2 daemon and saved process list, so automation needs shell access to the host rather than just an API token.\n- Structured output is partial: `jlist` and JSON logs are useful, but several inspect flows still default to formatted text.", "category": "dev-tools", "install": "npm install -g pm2", "github": "https:\/\/github.com\/Unitech\/pm2", "website": "https:\/\/pm2.keymetrics.io\/docs\/usage\/quick-start\/", "source_url": null, "stars": 42974, "language": "JavaScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "PM2.io" }, { "slug": "gh", "name": "GitHub CLI", "description": "GitHub CLI for pull requests, issues, repositories, Actions, releases, and authenticated API calls.", "long_description": "gh is GitHub's official CLI for working with repositories, pull requests, issues, releases, Actions, and search from the shell. It also includes `gh api` for direct REST and GraphQL calls when the built-in subcommands do not cover a workflow cleanly.\n\n## What It Enables\n- Create, review, merge, check out, and inspect pull requests; create, edit, comment on, and close issues without leaving the terminal.\n- Create or inspect repositories, releases, secrets, variables, projects, gists, and workflow runs, including reruns, cancellations, and artifact downloads.\n- Search across GitHub and send authenticated REST or GraphQL requests with `gh api` for repo-specific automation or gaps in higher-level commands.\n\n## Agent Fit\n- Repo-aware defaults and a broad noun-verb command surface make common GitHub tasks easy to compose in shell scripts and agent loops.\n- Real structured output is available across many commands via `--json`, `--jq`, and `--template`, and `gh api` can return raw API JSON when there is no dedicated subcommand.\n- Headless automation works best with tokens and explicit flags; browser login, confirmation prompts, and `--web` or watch-style commands are less suitable for unattended runs.\n\n## Caveats\n- JSON coverage is broad but not universal, so some workflows still fall back to `gh api` or plain-text parsing.\n- Authentication needs to be set up first; `gh auth login` defaults to browser-based flow, while CI or headless usage should rely on tokens in environment variables.", "category": "github", "install": "brew install gh", "github": "https:\/\/github.com\/cli\/cli", "website": "https:\/\/cli.github.com\/manual\/", "source_url": "https:\/\/cli.github.com", "stars": 42973, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "github", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "GitHub" }, { "slug": "tmux", "name": "tmux", "description": "Terminal multiplexer CLI for persistent sessions, pane management, input injection, and output capture across local or remote shells.", "long_description": "tmux is a terminal multiplexer that keeps shell sessions, windows, and panes alive behind a server you can detach from and reattach to later. Its CLI is most useful when work needs to survive SSH disconnects, run in parallel panes, or stay controllable after the original terminal closes.\n\n## What It Enables\n- Start detached sessions and windows for servers, watch commands, REPLs, or deploy loops that need to keep running in the background.\n- Split work across panes, send keystrokes or stdin to specific panes, and capture visible or historical pane output back to stdout or buffers.\n- Coordinate long-running local or remote terminal workflows with session, window, and pane IDs, pipes, custom formats, and `wait-for` synchronization.\n\n## Agent Fit\n- Commands such as `new-session -d`, `list-sessions -F`, `list-panes -F`, `send-keys`, `capture-pane -p`, and `pipe-pane` make tmux usable as a non-interactive control layer around persistent shell processes.\n- `-C` control mode adds a text protocol with `%begin`, `%end`, `%output`, and subscription notifications, but there is no JSON output mode for shell parsing.\n- Best when an agent needs durable terminal state or must revisit interactive program output later; less compelling when a task-specific CLI already exposes structured APIs directly.\n\n## Caveats\n- Automation is only as reliable as the programs inside the panes; prompts, full-screen apps, and shell startup differences can make input driving brittle.\n- In shared or multi-server setups, you need explicit socket, session, window, and pane targets to avoid acting on the wrong terminal state.", "category": "shell-utilities", "install": "brew install tmux", "github": "https:\/\/github.com\/tmux\/tmux", "website": "https:\/\/github.com\/tmux\/tmux\/wiki", "source_url": "https:\/\/github.com\/tmux\/tmux", "stars": 42712, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "pandoc", "name": "Pandoc", "description": "Document conversion CLI for turning Markdown, HTML, DOCX, EPUB, notebooks, and other markup formats into HTML, DOCX, slides, ebooks, and PDF output.", "long_description": "Pandoc is a document conversion CLI that reads many markup, publishing, and office formats into a shared document AST, then writes them back out as HTML, Markdown, DOCX, EPUB, slides, man pages, or PDF via external engines. It is most useful when you need repeatable content transformation, not interactive editing.\n\n## What It Enables\n- Convert source documents between Markdown, HTML, DOCX, EPUB, Jupyter notebooks, wiki formats, slide decks, and other text-centric formats in scripts or CI.\n- Generate publishable outputs such as HTML, DOCX, EPUB, man pages, presentations, and PDF files from source documents plus templates, metadata, citations, and style settings.\n- Apply custom document transformations with built-in citeproc, Lua filters, or JSON AST filters before emitting the target format.\n\n## Agent Fit\n- Explicit `--from` and `--to` flags, stdin\/stdout operation, defaults files, and list\/help commands make conversion jobs easy to inspect and rerun.\n- JSON support is real but AST-oriented: `-t json` and `-f json` expose Pandoc's document tree for filters, while most ordinary conversions emit target documents rather than machine-readable status.\n- Useful for agents that need to normalize content, generate derived artifacts, or apply repeatable document rewrites; less relevant for service control or state inspection tasks.\n\n## Caveats\n- PDF generation depends on external engines such as LaTeX, Groff ms, or HTML-based tooling, so unattended environments need those dependencies installed.\n- Conversions can be lossy between richer formats, and the server mode disables filters, PDF output, and HTTP resource fetching.", "category": "data-processing", "install": "brew install pandoc", "github": "https:\/\/github.com\/jgm\/pandoc", "website": "https:\/\/pandoc.org", "source_url": "https:\/\/pandoc.org", "stars": 42457, "language": "Haskell", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "fd", "name": "fd", "description": "Filesystem search CLI for finding paths by regex or glob with ignore-aware defaults, metadata filters, and command execution.", "long_description": "fd is a filesystem search CLI that finds files and directories by name or path, then narrows results with ignore rules and metadata filters. It covers the common cases where `find` feels verbose, while still letting you hand matches off to other shell commands.\n\n## What It Enables\n- Find files or directories by regex, glob, exact string, or full path while respecting `.gitignore`, `.ignore`, `.fdignore`, and hidden-file defaults.\n- Narrow large trees by type, extension, depth, size, modified time, owner, or custom exclude rules before taking follow-up action.\n- Feed matches into other commands with `--exec` or `--exec-batch`, or emit null-delimited and templated path output for pipelines such as `xargs`, `rm`, `rg`, or formatters.\n\n## Agent Fit\n- Non-interactive flags, predictable stdout, `--print0`, `--format`, and `--quiet` exit behavior make it easy to slot into search, select, and verify loops.\n- There is no real JSON mode, so agents have to parse paths, long listings, or custom templates rather than structured records.\n- Best as a local filesystem primitive inside broader workflows: locate the right files first, then hand them to editors, linters, search tools, or destructive commands deliberately.\n\n## Caveats\n- By default it skips hidden files and ignore-matched paths, which is convenient for humans but easy to miss in automation unless `-H`, `-I`, or `-u` is set deliberately.\n- `--exec` runs matches in parallel and `--exec-batch` does not guarantee argument order, so follow-up commands should not depend on traversal order.", "category": "file-management", "install": "brew install fd", "github": "https:\/\/github.com\/sharkdp\/fd", "website": null, "source_url": null, "stars": 41965, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "aider", "name": "Aider", "description": "AI coding assistant CLI for editing files, running lint or tests, and iterating on local codebases from the terminal.", "long_description": "Aider is a repo-aware coding assistant that works inside a local checkout, applies file edits on disk, and uses your existing git, test, and lint workflow from the terminal. It is built for iterative code changes in real projects, not just one-shot code generation.\n\n## What It Enables\n- Edit files in an existing repo from natural-language prompts, with repo mapping, read-only context files, and git-aware change tracking.\n- Run one-shot coding tasks with `--message` or keep an interactive session open to refine changes, inspect diffs, and undo or commit results.\n- Use lint, test, shell-command, and watch-file workflows so code changes can be checked and corrected inside the same terminal loop.\n\n## Agent Fit\n- Useful when an agent needs a coding-focused tool that can mutate a local repo, reuse project context, and iterate on failures in place.\n- The CLI has explicit non-interactive entrypoints for single prompts, but most output is conversational text rather than structured JSON that downstream tools can parse reliably.\n- Fits best as a higher-level coding primitive inside a repo workflow, especially when a skill can pin models, approval defaults, and project-specific test or lint commands.\n\n## Caveats\n- Real use depends on configuring an LLM provider or local model backend, and some features add optional browser or voice dependencies.\n- Default behavior is interactive and git-opinionated, so unattended use usually needs flags like `--message`, `--yes`, and explicit test or commit settings.", "category": "agent-harnesses", "install": "python -m pip install aider-install && aider-install", "github": "https:\/\/github.com\/Aider-AI\/aider", "website": "https:\/\/aider.chat\/", "source_url": "https:\/\/aider.chat\/docs\/install.html", "stars": 41640, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Aider" }, { "slug": "payload", "name": "Payload CLI", "description": "Official Payload CLI for scaffolding projects and running migrations, type generation, job workers, and custom scripts in Payload apps.", "long_description": "Payload exposes two official CLI surfaces in this repo: `create-payload-app` for bootstrapping or installing Payload into a Next.js app, and the in-project `payload` bin for migrations, code generation, workers, and custom scripts. It is a project-operations CLI for building and maintaining Payload apps rather than a remote content-management CLI.\n\n## What It Enables\n- Scaffold a new Payload app or install Payload into an existing Next.js project, choosing templates, database setup, package manager, and initial env files.\n- Run database migrations, generate TypeScript types and Drizzle schema, and regenerate admin import maps from the local Payload config.\n- Execute background job workers and schedule handlers, or register project-specific `payload ` scripts for seeders and other maintenance tasks.\n\n## Agent Fit\n- Works best inside a checked-out Payload app with config and env already present, where commands become deterministic and scriptable.\n- Good shell fit for CI and maintenance loops such as migrations, code generation, and worker processes, but output is mostly plain text or file writes instead of structured JSON.\n- Setup still leans on interactive prompts unless template, database, and other flags are supplied up front; official MCP support exists through the separate `@payloadcms\/plugin-mcp` package.\n\n## Caveats\n- The entry is conceptually split across `create-payload-app` and the `payload` bin, so users expecting one single CLI surface may find the packaging slightly confusing.\n- Most day-to-day content reads and writes happen through Payload APIs, app code, or the admin UI rather than through this CLI.", "category": "http-apis", "install": "npx create-payload-app", "github": "https:\/\/github.com\/payloadcms\/payload", "website": "https:\/\/payloadcms.com\/docs\/getting-started\/installation", "source_url": "https:\/\/payloadcms.com\/docs\/getting-started\/what-is-payload", "stars": 41051, "language": "TypeScript", "has_mcp": true, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Payload CMS" }, { "slug": "wrk", "name": "wrk", "description": "HTTP benchmarking CLI for load testing web services with concurrent connections, latency stats, and Lua scripting hooks.", "long_description": "wrk is a command-line HTTP benchmarking tool for driving high-concurrency load against a web service from a single machine. It focuses on throughput, latency, and error-rate measurement, with Lua hooks when you need more than a fixed request.\n\n## What It Enables\n- Run repeatable HTTP or HTTPS benchmarks with configurable threads, open connections, duration, headers, timeouts, and optional latency breakdowns.\n- Exercise custom request patterns with Lua, including POST bodies, dynamic request generation, delays, per-response inspection, and custom end-of-run summaries.\n- Compare request rate, transfer rate, latency, and error counts before and after deploys, config changes, or infrastructure tuning.\n\n## Agent Fit\n- The CLI surface is small, non-interactive, and easy to rerun in scripts or CI when an agent needs a quick load or regression check against a known endpoint.\n- Automation is weaker than the benchmark engine itself: default results are text summaries, there is no built-in JSON flag, and richer machine-readable reporting usually means custom Lua or stdout parsing.\n- Best used as a verification primitive in deploy and performance loops where the agent already knows the target URL and the thresholds that should fail the workflow.\n\n## Caveats\n- Client-side limits matter: README notes ephemeral ports, socket recycling, and listen backlog tuning can distort results if the load generator is the bottleneck.\n- Completed runs do not fail on bad HTTP statuses by themselves, so agents need explicit parsing or scripted reporting to turn benchmark output into pass or fail signals.", "category": "testing", "install": "make", "github": "https:\/\/github.com\/wg\/wrk", "website": null, "source_url": "https:\/\/github.com\/wg\/wrk", "stars": 40118, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "shellcheck", "name": "ShellCheck", "description": "Static analysis CLI for shell scripts that catches bugs, portability issues, and unsafe shell patterns before they ship.", "long_description": "ShellCheck is a static analysis CLI for POSIX `sh`, `bash`, `dash`, `ksh`, and BusyBox shell scripts. It focuses on catching syntax mistakes, quoting bugs, portability problems, and other shell-specific failure modes before they reach production or CI.\n\n## What It Enables\n- Lint shell scripts in repos, build steps, hooks, or generated checks and fail fast when they introduce warnings above your chosen severity.\n- Surface shell-specific portability and correctness issues that depend on the target shell, sourced files, optional checks, or project-level rc configuration.\n- Export findings as JSON for downstream parsing or as unified diffs for supported auto-fixes that can be reviewed and applied with standard patch tools.\n\n## Agent Fit\n- Structured `json1` output, documented exit codes, and non-interactive flags make it easy to drop into CI, pre-commit, or inspect-then-fix agent loops.\n- Directives, `.shellcheckrc`, `--shell`, `--severity`, and source-path controls let an agent adapt checks to the repo instead of treating every shell file the same.\n- It is a diagnostic primitive, not a mutating one: most findings still need a separate edit step, and sourced-file coverage can be incomplete until `-x`, `-a`, or rc settings are configured.\n\n## Caveats\n- Default source handling is conservative because the tool originated as a remote service for untrusted scripts; multi-file projects may need `--external-sources`, `--source-path`, or `.shellcheckrc` setup.\n- `diff` output only covers fixes ShellCheck can express safely, so many warnings remain advisory and require manual or agent-authored edits.", "category": "dev-tools", "install": "brew install shellcheck", "github": "https:\/\/github.com\/koalaman\/shellcheck", "website": "https:\/\/www.shellcheck.net", "source_url": "https:\/\/www.shellcheck.net", "stars": 39074, "language": "Haskell", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "istioctl", "name": "istioctl", "description": "Istio CLI for installing and upgrading meshes, inspecting proxy and ztunnel state, and debugging service mesh configuration on Kubernetes.", "long_description": "istioctl is the operational CLI for working with an Istio service mesh from the shell. It spans install and upgrade work, deep proxy and ambient-mesh inspection, and config analysis against live clusters or exported dumps.\n\n## What It Enables\n- Install, upgrade, uninstall, or render Istio control-plane manifests, then run prechecks before changing a cluster.\n- Inspect Envoy config dumps, ztunnel state, authorization policy effects, and waypoint status to troubleshoot routing, policy, and ambient mesh behavior.\n- Analyze or validate Istio resources, create multicluster remote secrets, and generate VM or non-Kubernetes workload onboarding config.\n\n## Agent Fit\n- Useful in agent loops because the command surface is broad, non-TUI, and parameterized around kubeconfig, context, namespace, and revision flags.\n- Important inspection paths such as `proxy-config`, `ztunnel-config`, and `tag list` support JSON or YAML output, and some commands can read exported config-dump files instead of talking to a live pod.\n- Most value still depends on cluster credentials and a running mesh, while dashboard helpers and some `experimental` commands are less suitable for unattended automation.\n\n## Caveats\n- Real use is Kubernetes-centric and often requires an Istio control plane already installed; without cluster access the tool falls back to a smaller file-based subset.\n- Istio recommends matching the `istioctl` version to the control-plane version, and many commands default to human-readable tables rather than structured output.", "category": "networking", "install": "curl -sL https:\/\/istio.io\/downloadIstioctl | sh -", "github": "https:\/\/github.com\/istio\/istio", "website": "https:\/\/istio.io\/latest\/docs\/ops\/diagnostic-tools\/istioctl\/", "source_url": "https:\/\/istio.io", "stars": 38088, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "inso", "name": "Insomnia CLI", "description": "CLI for running Insomnia API collections and test suites, linting API specs, and exporting saved design documents.", "long_description": "Inso is Insomnia's automation-focused CLI for taking API collections and specs out of the desktop app and into the shell. It runs request collections and unit test suites, lints API specs, and exports stored designs from Insomnia app data, Git-backed projects, or export files.\n\n## What It Enables\n- Run saved request collections against chosen environments, globals, iteration data, and scripted request flows without opening the Insomnia app.\n- Execute Insomnia unit test suites in CI, including request scripts, proxy settings, timeout controls, certificate toggles, and fail-fast exit behavior.\n- Lint OpenAPI specs with Spectral rulesets and export API specs from Insomnia workspaces or export files for downstream validation or publishing.\n\n## Agent Fit\n- Useful when a team already stores API definitions or test suites in Insomnia, because commands accept export files, Git-backed projects, or local app data and support `--ci` to suppress prompts.\n- Machine-readable output exists, but narrowly: `run collection --output` writes JSON reports with safe, redacted, or plaintext detail, while most other commands emit human-oriented logs rather than `--json` stdout.\n- No native MCP surface or packaged skills tree was found for `inso`; MCP code in this monorepo belongs to the desktop Insomnia app, not the CLI.\n\n## Caveats\n- The CLI is tightly coupled to Insomnia's data model and identifiers, so it is much less useful if your API definitions and tests live outside Insomnia.\n- Some flows still prompt for workspace or environment selection unless you pass explicit identifiers or use `--ci`, and collection runs can execute embedded scripts with filesystem access scoped by `--dataFolders`.", "category": "http-apis", "install": "brew install inso", "github": "https:\/\/github.com\/Kong\/insomnia", "website": "https:\/\/developer.konghq.com\/inso-cli\/", "source_url": "https:\/\/docs.insomnia.rest\/inso-cli\/introduction", "stars": 38015, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Kong" }, { "slug": "httpie", "name": "HTTPie", "description": "HTTP client CLI for sending API requests, inspecting responses, and reusing auth, headers, and cookies with sessions.", "long_description": "HTTPie is a command-line HTTP client for working with APIs and other HTTP services using concise request syntax. It covers ad hoc requests, auth, headers, uploads, downloads, and reusable sessions without dropping to raw `curl` calls.\n\n## What It Enables\n- Send API requests with explicit methods, headers, query params, JSON or form fields, file uploads, proxies, TLS options, and multiple auth modes from one command surface.\n- Inspect responses with selectable headers, body, and metadata output, or use `--offline` to build and review a request before sending it.\n- Reuse cookies, auth, and custom headers across calls with session files, and download or stream response bodies inside shell workflows.\n\n## Agent Fit\n- Commands are mostly non-interactive and expose clear flags for methods, request data, redirects, timeouts, sessions, and output selection, which works well in inspect\/change\/verify loops.\n- Machine-readability is limited: `--json` controls request construction, and response JSON support is mainly pretty-printing rather than a dedicated structured output mode.\n- Automation is reliable only when you pin flags like `--check-status`, `--pretty=none`, and `--print`; terminal defaults otherwise change formatting and HTTP errors still exit 0.\n\n## Caveats\n- Some auth flows and certificate prompts can become interactive, and session files persist credentials, headers, and cookies on disk.\n- HTTPie is a generic HTTP primitive rather than a service-specific CLI, so higher-level workflows still require knowing the target API.", "category": "http-apis", "install": "brew install httpie", "github": "https:\/\/github.com\/httpie\/cli", "website": "https:\/\/httpie.io", "source_url": null, "stars": 37654, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "HTTPie" }, { "slug": "duckdb", "name": "DuckDB CLI", "description": "Analytical SQL database CLI for querying, transforming, and exporting CSV, Parquet, JSON, and DuckDB data.", "long_description": "DuckDB CLI is the standalone shell for DuckDB's analytical SQL engine. It lets you run ad hoc or scripted SQL against DuckDB databases and file-based datasets without standing up a separate database server.\n\n## What It Enables\n- Query, join, and aggregate CSV, Parquet, JSON, and DuckDB data directly from the terminal.\n- Create local analytical databases, import data, and export results in formats like CSV, JSON, and NDJSON.\n- Run repeatable inspection, transformation, and reporting steps from one-off commands, SQL files, or shell pipelines.\n\n## Agent Fit\n- `-c`, `-s`, `-f`, and stdin support make it easy to drop into batch jobs, CI steps, and multi-command agent loops.\n- JSON and JSON Lines output modes give agents structured results they can parse and feed into follow-up commands.\n- The surface is powerful but SQL-centric, so agent success depends on generating correct queries and iterating on schema discovery rather than calling high-level task-specific subcommands.\n\n## Caveats\n- Many useful workflows rely on writing SQL rather than invoking purpose-built verbs, which raises the bar for reliable autonomous use.\n- The shell can read and write local files and run shell-adjacent commands unless you enable `-safe` or otherwise constrain the environment.", "category": "databases", "install": "curl https:\/\/install.duckdb.org | sh", "github": "https:\/\/github.com\/duckdb\/duckdb", "website": "https:\/\/duckdb.org\/docs\/stable\/clients\/cli\/overview", "source_url": null, "stars": 36495, "language": "C++", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "DuckDB Foundation" }, { "slug": "vault", "name": "Vault CLI", "description": "HashiCorp CLI for reading and writing Vault secrets, managing auth, policies, tokens, and leases, and operating Vault clusters.", "long_description": "Vault CLI is HashiCorp's command surface for secret management, authentication, policy control, and day-to-day Vault operations. It covers both application-facing secret access and operator tasks such as token, lease, auth, audit, and cluster administration.\n\n## What It Enables\n- Read, write, list, patch, and delete secrets or configuration at Vault API paths, including KV, transit, PKI, and other mounted engines.\n- Log in with supported auth methods and manage tokens, leases, policies, auth mounts, secret engines, namespaces, and audit devices from the shell.\n- Check seal or HA health, inspect operator or raft state, stream server logs, and run `vault agent` or `vault proxy` for auto-auth and secret delivery.\n\n## Agent Fit\n- Global `-format=json` and `VAULT_FORMAT=json`, plus `-field` and stdin input, make many inspect and mutation commands easy to chain into parse-and-act loops.\n- The command surface mirrors Vault's HTTP API, so agents can use generic verbs like `read` and `write` or switch to more focused groups such as `kv`, `token`, and `operator` when the workflow needs them.\n- Automation fit depends on environment: a reachable Vault instance, credentials, TLS material, and sometimes config-managed long-running processes are prerequisites.\n\n## Caveats\n- Most commands are only useful against an existing Vault deployment; local invocation alone does not provide secret storage or service state.\n- Auth and admin flows can become interactive with prompts, MFA, or token-helper behavior unless credentials and non-interactive settings are supplied explicitly.", "category": "security", "install": "brew install hashicorp\/tap\/vault", "github": "https:\/\/github.com\/hashicorp\/vault", "website": "https:\/\/developer.hashicorp.com\/vault\/docs\/commands", "source_url": "https:\/\/developer.hashicorp.com\/vault\/docs\/install", "stars": 35174, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "HashiCorp" }, { "slug": "directus", "name": "Directus CLI", "description": "Official Directus CLI for bootstrapping self-hosted projects, migrating the database, and snapshotting or applying schema.", "long_description": "Directus CLI is the server-side command surface for setting up and operating a self-hosted Directus project. It focuses on project bootstrap, database lifecycle, schema promotion, and a small set of admin tasks against the instance database.\n\n## What It Enables\n- Create or bootstrap a self-hosted Directus project, install or migrate the database, and start the API.\n- Snapshot a Directus schema to YAML or JSON, preview changes with `--dry-run`, and apply schema updates between environments.\n- Create roles and users, reset user passwords, and run simple maintenance checks such as collection counts against the project database.\n\n## Agent Fit\n- `schema snapshot --format json`, `schema apply --dry-run`, and `--yes` support make schema promotion and verification workable in scripts or CI.\n- The surface is mixed rather than broad: most commands assume a local project directory, configured database environment, or human prompts, especially `init`.\n- Directus itself can expose an `\/mcp` endpoint when the server is running, but this package is mainly a deployment and schema-management CLI, not the richer client-side `directusctl` automation surface.\n\n## Caveats\n- Most day-to-day content reads and writes happen through the Directus REST or GraphQL APIs, or the separate `directusctl` CLI, rather than this server-side package.\n- Useful operation requires a configured project and database connection, and `init` installs drivers and prompts for database and admin details.", "category": "http-apis", "install": "npm init directus-project ", "github": "https:\/\/github.com\/directus\/directus", "website": "https:\/\/docs.directus.io\/self-hosted\/cli", "source_url": "https:\/\/directus.io\/docs\/self-hosted\/cli", "stars": 34410, "language": "TypeScript", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Directus" }, { "slug": "croc", "name": "croc", "description": "Secure file transfer CLI for sending files, folders, and text between computers over public or self-hosted relays.", "long_description": "croc is a peer-to-peer file transfer CLI for sending files, folders, or short text between two machines using a shared code phrase and a relay for rendezvous. It covers ad hoc cross-machine transfers when SSH, shared storage, or a longer-lived sync setup is not the right fit.\n\n## What It Enables\n- Send files, folders, or short text from one machine to another with end-to-end encryption and resumable transfers.\n- Stream data from stdin into a transfer or receive directly to stdout, which helps move artifacts through shell pipelines.\n- Run your own relay and relay password so transfers stay on infrastructure you control instead of the default public relay.\n\n## Agent Fit\n- Non-interactive flags such as `--yes`, `--overwrite`, `--stdout`, `--out`, `--relay`, and `--text` make scripted transfers feasible.\n- There is no user-facing JSON or other structured output mode, so follow-up parsing relies on human-readable logs and exit status.\n- Best fit is artifact handoff between machines or sessions; coordination still depends on both sides sharing a code phrase and running paired sender and receiver commands.\n\n## Caveats\n- On Linux and macOS, secure usage expects the secret in `CROC_SECRET`; passing it on the command line requires opting back into classic mode with an explicit local-security tradeoff.\n- Unattended workflows are narrower than tools like `scp` or object-store CLIs because a receiver still needs the matching code phrase and a live transfer session.", "category": "utilities", "install": "curl https:\/\/getcroc.schollz.com | bash", "github": "https:\/\/github.com\/schollz\/croc", "website": "https:\/\/schollz.com\/software\/croc6", "source_url": null, "stars": 34326, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "pnpm", "name": "pnpm", "description": "Node.js package manager for installing dependencies, managing workspaces, and running package scripts.", "long_description": "pnpm is a Node.js package manager for dependency installs, lockfile-driven updates, and workspace orchestration in JavaScript and TypeScript repos. It covers the core repo lifecycle from adding packages and running scripts to auditing and inspecting dependency state.\n\n## What It Enables\n- Install, add, remove, update, fetch, and dedupe packages while keeping `package.json` and `pnpm-lock.yaml` aligned.\n- Run package scripts, one-off package binaries, and recursive workspace commands across selected projects with filters.\n- Inspect dependency trees, outdated versions, vulnerabilities, licenses, and why a package is present before changing or releasing a repo.\n\n## Agent Fit\n- Recursive filters, stable command names, and script-oriented subcommands make it effective inside CI and repo automation loops.\n- Structured output exists but is not uniform: review commands such as `list`, `outdated`, `audit`, and `licenses` expose JSON modes, and `--reporter ndjson` can stream logs.\n- Best fit when an agent is already operating inside a Node repo and needs to manage dependencies or run project tasks defined by that repo.\n\n## Caveats\n- Install and update flows mutate `package.json`, `pnpm-lock.yaml`, and `node_modules`, and dependency lifecycle scripts may run unless policy blocks them.\n- Behavior depends on repo manifests, lockfiles, workspace config, and registry auth, so unattended runs need project context and credentials.", "category": "package-managers", "install": "curl -fsSL https:\/\/get.pnpm.io\/install.sh | sh -", "github": "https:\/\/github.com\/pnpm\/pnpm", "website": "https:\/\/pnpm.io\/", "source_url": null, "stars": 34260, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "pnpm", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "jq", "name": "jq", "description": "Command-line JSON processor for querying, reshaping, validating, and streaming JSON data.", "long_description": "jq is a command-line JSON processor that runs filters over JSON from stdin or files and emits transformed results to stdout. It is a core shell primitive for inspecting, validating, reshaping, and generating structured data between other commands.\n\n## What It Enables\n- Extract fields, filter arrays, join values, and reshape JSON payloads from APIs, config files, logs, and other CLI output.\n- Validate and pretty-print JSON, or emit compact, sorted, raw-string, or JSON-seq output for downstream commands.\n- Build JSON from scratch with `-n`, pass structured values with `--argjson` or `--jsonargs`, and handle very large documents with `--stream`.\n\n## Agent Fit\n- Default stdout is structured JSON, and `-c` or `--seq` keep it easy to pipe into follow-up steps.\n- It works cleanly in non-interactive stdin or file workflows, with exit codes and stderr behavior that suit inspect, transform, and verify loops.\n- Best used as a companion primitive around other tools that emit JSON; agents still need to learn jq syntax for complex reductions and streaming transforms.\n\n## Caveats\n- It does not authenticate to services or mutate remote systems on its own; it only transforms local input and output streams.\n- Shell quoting and the filter language are common failure points on first attempt, especially across different shells.", "category": "data-processing", "install": "brew install jq", "github": "https:\/\/github.com\/jqlang\/jq", "website": "https:\/\/jqlang.org\/manual\/", "source_url": null, "stars": 33821, "language": "C", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "trivy", "name": "Trivy", "description": "Security scanner for container images, repositories, filesystems, Kubernetes, and SBOMs, with vulnerability, misconfiguration, secret, and license checks.", "long_description": "Trivy is Aqua Security's CLI for scanning software artifacts and infrastructure targets for security findings. It covers container images, filesystems, Git repositories, Kubernetes clusters, VM images, and SBOM documents, and can emit compliance or supply-chain reports for CI and remediation workflows.\n\n## What It Enables\n- Scan container images, local filesystems, Git repositories, VM images, and SBOM documents for vulnerabilities, secrets, licenses, and exposed package inventories.\n- Check Terraform, Helm, Kubernetes, Dockerfile, CloudFormation, Azure ARM, and Ansible configs before deploy, or scan live Kubernetes clusters with compliance report modes.\n- Export findings as JSON, SARIF, CycloneDX, SPDX, GitHub dependency snapshots, or converted reports for CI gates, dashboards, and attestations.\n\n## Agent Fit\n- Non-interactive subcommands, target-specific flags, and `--exit-code` controls make it easy to wire into CI, pre-deploy checks, and retryable agent loops.\n- `--format json` plus SARIF, CycloneDX, and SPDX outputs give agents machine-readable results, and the reporting flags document which behaviors are format-specific.\n- Environment access still matters: first runs may download vulnerability databases and check bundles, some targets need registry or cluster credentials, and the `kubernetes` surface is still marked experimental.\n\n## Caveats\n- Default output is a human table, so automation should request an explicit structured format.\n- Coverage and accepted formats vary by subcommand; for example `kubernetes` only supports table, JSON, and CycloneDX output, and `convert` does not support AWS or Kubernetes JSON reports.", "category": "security", "install": "brew install trivy", "github": "https:\/\/github.com\/aquasecurity\/trivy", "website": "https:\/\/trivy.dev\/docs\/latest\/", "source_url": null, "stars": 33019, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Aqua Security" }, { "slug": "certbot", "name": "Certbot", "description": "Official ACME client from EFF for obtaining, renewing, and automating TLS certificates from the terminal.", "long_description": "Official ACME client from EFF for obtaining, renewing, and automating TLS certificates from the terminal.\n\n## Highlights\n- Installs with `brew install certbot`\n- Primary implementation language is Python\n- Maintained by the upstream EFF team\n\n## Agent Fit\n- Fits shell scripts and agent workflows that need a terminal-native interface\n- Straightforward installation helps bootstrap local or ephemeral automation environments", "category": "security", "install": "brew install certbot", "github": "https:\/\/github.com\/certbot\/certbot", "website": "https:\/\/certbot.eff.org\/", "source_url": "https:\/\/certbot.eff.org\/", "stars": 32886, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "EFF" }, { "slug": "cockroach", "name": "CockroachDB CLI", "description": "CockroachDB CLI for running SQL, managing nodes and certificates, handling userfile storage, and collecting cluster diagnostics.", "long_description": "`cockroach` is the command line interface bundled with CockroachDB for starting nodes, connecting with a built-in SQL client, and running cluster administration or troubleshooting commands. It covers both day-to-day operator tasks and direct SQL access against local or remote CockroachDB clusters.\n\n## What It Enables\n- Start or initialize self-managed clusters, open the built-in SQL client, or run non-interactive SQL and format results for follow-up shell processing.\n- Inspect node membership and status, generate certificates, create or revoke web auth sessions, and move files through `userfile` storage from the terminal.\n- Download statement diagnostics bundles, build `debug zip` support archives, and run low-level debug or recovery commands against cluster and store data.\n\n## Agent Fit\n- Most client commands are non-interactive by default, and the shared `--format` flag exposes structured JSON or NDJSON output on SQL, node, auth, debug zip, and related table-printing commands.\n- Good fit for inspect-change-verify loops around an existing CockroachDB deployment because the same binary can query SQL state, check node health, stage files, and collect diagnostics.\n- Mixed overall: a lot of value depends on having a reachable cluster plus credentials or TLS material, and `cockroach sql`, `demo`, or secure setup flows can still become interactive.\n\n## Caveats\n- Useful automation assumes a reachable CockroachDB node and the right connection settings, certificates, or admin privileges; several commands target system-level operations.\n- This is a combined server and admin binary, so some subcommands are meant for operators or support workflows rather than general database scripting.", "category": "databases", "install": "brew install cockroachdb\/tap\/cockroach", "github": "https:\/\/github.com\/cockroachdb\/cockroach", "website": "https:\/\/www.cockroachlabs.com\/docs\/stable\/cockroach-commands", "source_url": "https:\/\/www.cockroachlabs.com\/docs\/stable\/cockroach-commands", "stars": 31997, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "CockroachDB" }, { "slug": "glances", "name": "Glances", "description": "Cross-platform system monitoring CLI with a curses dashboard, web\/API server, and JSON metric export.", "long_description": "Glances is a cross-platform host monitoring CLI that can run as a local curses dashboard, a web or API server, or a stdout exporter. It is built for inspecting live system health across CPU, memory, disks, network, processes, containers, and other plugins.\n\n## What It Enables\n- Watch live host and process health locally, or connect to remote Glances servers for centralized monitoring.\n- Export selected metrics as stdout JSON, CSV, or REST responses that can feed scripts, logging, alerts, or follow-up shell steps.\n- Expose browser and API views for the same host metrics when you need remote access or lightweight dashboards.\n\n## Agent Fit\n- `--stdout-json` and the REST API give agents structured telemetry they can poll, diff, and route into later decisions.\n- This is much stronger for inspect and verify loops than for change workflows, because Glances reports system state but does not manage services or remediate issues itself.\n- MCP support is real but optional; for most shell automation, direct JSON output or HTTP endpoints are the simpler integration surface.\n\n## Caveats\n- Base installation is small, but web, export, and MCP features require optional extras such as `glances[all]` or `glances[mcp]`.\n- Available plugins and fields vary by platform and by which optional dependencies are installed for containers, sensors, GPU, SMART, and similar data sources.", "category": "system-monitoring", "install": "pip install glances", "github": "https:\/\/github.com\/nicolargo\/glances", "website": "https:\/\/nicolargo.github.io\/glances\/", "source_url": null, "stars": 31995, "language": "Python", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "just", "name": "just", "description": "Command runner for defining, listing, and executing project recipes from a `justfile`.", "long_description": "just is a project-local command runner that reads recipes from a `justfile` and executes them with parameters, dependencies, dotenv loading, and shell integration. It is most useful when a repo wants one discoverable entry point for build, test, deploy, and maintenance commands.\n\n## What It Enables\n- Define named project tasks once and run them consistently from any subdirectory that can find the repo's `justfile`.\n- List available recipes, inspect recipe definitions, and expose repo automation entry points without reading shell scripts by hand.\n- Run build, test, deploy, and maintenance recipes with arguments, dependencies, dotenv loading, or arbitrary shebang languages.\n\n## Agent Fit\n- `--list`, `--summary`, `--show`, and `--dump --dump-format json` make existing project workflows discoverable and parsable before execution.\n- Commands are non-interactive by default, honor exit codes, and `--dry-run` helps agents preview effects before running recipes.\n- Best when a repo already captures useful operations in a `justfile`; `just` is a control layer over project scripts, not a service CLI with a fixed cross-project action surface.\n\n## Caveats\n- Automation value depends entirely on the local `justfile`; a repo with weak or unsafe recipes gives agents little reliable leverage.\n- Some features lean interactive or human-oriented, such as `--choose` via `fzf` and `--edit`, and recipe bodies can run arbitrary shell code.", "category": "dev-tools", "install": "brew install just", "github": "https:\/\/github.com\/casey\/just", "website": "https:\/\/just.systems", "source_url": null, "stars": 31906, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "continue", "name": "Continue", "description": "Coding-agent CLI for repo-aware chat, headless tasks, diff-based reviews, and Continue-managed assistant or MCP configs.", "long_description": "Continue CLI (`cn`) is a terminal coding agent that can run interactive sessions or one-shot headless tasks against a local checkout. It shares assistants, rules, and MCP configuration with Continue's hosted platform and editor extensions.\n\n## What It Enables\n- Run repo-aware coding tasks that read files, execute commands, edit code, and resume prior sessions from the terminal.\n- Review local diffs with `cn review`, get text or JSON reports, emit patches, and optionally apply suggested fixes to the working tree.\n- Use Continue-managed assistants, rules, and MCP servers from the shell, plus inspect PR check results with `cn checks` or expose a remote agent session with `cn serve` and `cn remote`.\n\n## Agent Fit\n- Headless `-p`, TTY-less safeguards, `cn ls --json`, and `cn review --format json` make it usable in scripts, CI jobs, and editor-driven loops.\n- A lot of the value still flows through an LLM conversation loop, so results are less deterministic than narrow service CLIs and often need prompt, model, or permission tuning.\n- Fits best as a higher-level repo automation layer when a skill pins the config, allowed tools, review agents, and any optional MCP servers.\n\n## Caveats\n- Unattended use needs authentication up front through `cn login`, `CONTINUE_API_KEY`, or an Anthropic key, and default mode is still interactive.\n- Headless `--format json` guarantees parseable JSON, but chat responses may be wrapped model text rather than a fixed schema unless you control the prompt and workflow.", "category": "ai-agents", "install": "curl -fsSL https:\/\/raw.githubusercontent.com\/continuedev\/continue\/main\/extensions\/cli\/scripts\/install.sh | bash", "github": "https:\/\/github.com\/continuedev\/continue", "website": "https:\/\/docs.continue.dev\/cli\/quickstart", "source_url": "https:\/\/continue.dev", "stars": 31714, "language": "TypeScript", "has_mcp": true, "has_skill": true, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": true, "source_type": "github", "vendor_name": "Continue" }, { "slug": "minikube", "name": "minikube", "description": "Local Kubernetes cluster CLI for starting clusters, enabling addons, exposing services, and testing Kubernetes workflows on a developer machine.", "long_description": "minikube creates and manages local Kubernetes clusters on a developer machine. It wraps cluster startup, driver selection, addon management, and local-access workflows around a disposable Kubernetes environment.\n\n## What It Enables\n- Start, stop, pause, delete, and manage multiple named local clusters with different Kubernetes versions, drivers, node counts, runtimes, and addon selections.\n- Expose local services and LoadBalancers with `service` and `tunnel`, open the dashboard, and point local image builds at the cluster with `docker-env`.\n- Check cluster, node, version, and addon state before handing workload operations off to `kubectl` against the cluster it created.\n\n## Agent Fit\n- Several high-value commands support structured output, including `status --output json`, `version -o json`, `docker-env -o json`, `addons list -o json`, and lifecycle commands such as `start` or `stop` with `--output=json`.\n- Useful when an agent needs to provision, reset, or inspect a disposable local cluster before running `kubectl`, tests, or platform setup steps.\n- Less clean for unattended automation than cloud CLIs because success depends on local drivers and privileges, and helpers like `dashboard`, `service`, or `tunnel` can open browsers or require a live terminal.\n\n## Caveats\n- It manages the local cluster environment rather than general Kubernetes resources, so most workload changes still happen through `kubectl`.\n- Driver setup, container runtime availability, and privileged networking can be the real source of failure, not the CLI syntax.", "category": "containers", "install": "brew install minikube", "github": "https:\/\/github.com\/kubernetes\/minikube", "website": "https:\/\/minikube.sigs.k8s.io\/docs\/", "source_url": "https:\/\/minikube.sigs.k8s.io\/docs\/", "stars": 31563, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Kubernetes" }, { "slug": "podman", "name": "Podman", "description": "Container engine CLI for running, building, inspecting, and publishing OCI containers, images, pods, and volumes.", "long_description": "Podman is the official CLI for managing OCI containers, images, pods, volumes, and container-host connections without a long-running central daemon. It covers local Linux workflows plus remote or VM-backed use on macOS and Windows.\n\n## What It Enables\n- Run, inspect, exec into, stop, and remove containers or pods, then manage the related images, networks, and volumes from one CLI.\n- Build, tag, search, pull, sign, and push container images against local or remote registries, including rootless workflows on Linux.\n- Generate Kubernetes YAML or systemd units, start an API service, and manage Podman machines or remote connections for local development and deployment handoff.\n\n## Agent Fit\n- Many high-value read paths support JSON through `inspect` or `--format json`, which makes follow-up parsing and verification straightforward.\n- Docker-like verbs plus mostly non-interactive flags fit shell scripts and CI well, and `system connection` or `machine` commands let agents target local or remote Linux backends consistently.\n- Useful automation depends more on environment than syntax: agents still need a working Linux backend, container storage, registry auth, and sometimes systemd or SSH access.\n\n## Caveats\n- On macOS and Windows, most container execution goes through `podman machine` or another remote Linux host rather than running natively on the host OS.\n- Rootless mode is strong but not seamless: low ports, NFS-backed home directories, and some networking or checkpoint flows have documented limitations.", "category": "containers", "install": "brew install podman", "github": "https:\/\/github.com\/containers\/podman", "website": "https:\/\/docs.podman.io\/", "source_url": null, "stars": 30934, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "podman", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Podman" }, { "slug": "k6", "name": "k6", "description": "Load-testing CLI for JavaScript performance tests across HTTP, gRPC, WebSocket, and browser workflows.", "long_description": "k6 is Grafana's load-testing CLI for writing performance tests in JavaScript and running them locally or in Grafana Cloud. It covers API, protocol, and browser journeys while collecting thresholds, summaries, and exportable metrics.\n\n## What It Enables\n- Run repeatable load tests for HTTP APIs, gRPC services, WebSockets, and browser flows from versioned JavaScript scripts.\n- Inspect effective options, dependency requirements, and execution requirements before a run, then archive a self-contained test for CI or remote execution.\n- Export summaries and metrics to JSON files or external backends such as OpenTelemetry, Prometheus Remote Write, InfluxDB, and Grafana Cloud.\n\n## Agent Fit\n- Core workflows are non-interactive and scriptable, so agents can inspect a test, run it with explicit flags, and gate follow-up actions on thresholds or exported metrics.\n- Machine-readable paths are real: `k6 inspect` returns JSON, `k6 deps --json` lists imports and build requirements, `--summary-export` writes JSON, and `-o json` streams newline-delimited metrics.\n- Project-level MCP support exists through the separate experimental `mcp-k6` server documented by Grafana, but the main `k6` binary remains the primary action surface.\n\n## Caveats\n- Writing useful tests still requires domain knowledge about traffic shape, thresholds, and environments; k6 measures behavior but does not explain regressions on its own.\n- Browser scenarios and cloud runs add heavier setup, including local browser dependencies or Grafana Cloud authentication.", "category": "testing", "install": "brew install k6", "github": "https:\/\/github.com\/grafana\/k6", "website": "https:\/\/grafana.com\/docs\/k6\/latest\/", "source_url": null, "stars": 30064, "language": "Go", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Grafana" }, { "slug": "consul", "name": "Consul", "description": "Service networking CLI for running Consul agents, querying service discovery state, and managing mesh, peerings, and cluster operations.", "long_description": "Consul is HashiCorp's CLI for running and operating Consul agents and clusters across service discovery, service mesh, and control-plane workflows. It spans local-agent actions and higher-level cluster administration such as catalog, config, resources, peerings, and snapshots.\n\n## What It Enables\n- Run or join agents, inspect members, stream logs, and troubleshoot service-mesh connectivity from the shell.\n- Register or deregister services, query catalog and KV state, and read or update config and resource objects against Consul APIs.\n- Operate cluster features such as peerings, exported services, ACL-related workflows, and verified server snapshots.\n\n## Agent Fit\n- The command surface is broad and mostly non-interactive once addresses, partitions, and auth are configured, so it fits shell-driven inspect, change, and verify loops.\n- Structured output is real but uneven: resource and config reads emit JSON directly, and peering or autopilot commands support `-format=json`.\n- Agents fit best when they already know which Consul address, namespace, partition, and ACL token to use, because many commands are thin clients over a reachable local or remote agent.\n\n## Caveats\n- Useful automation depends on running Consul agents or servers plus valid network access and often ACL credentials.\n- Some features are enterprise-only, and several read paths still default to human-oriented text instead of a universal JSON mode.", "category": "networking", "install": "brew tap hashicorp\/tap && brew install hashicorp\/tap\/consul", "github": "https:\/\/github.com\/hashicorp\/consul", "website": "https:\/\/developer.hashicorp.com\/consul\/commands", "source_url": "https:\/\/developer.hashicorp.com\/consul", "stars": 29780, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "HashiCorp" }, { "slug": "helm", "name": "Helm", "description": "Kubernetes CLI for packaging charts, rendering manifests, and installing, upgrading, or rolling back releases.", "long_description": "Helm is the package manager and release CLI for Kubernetes applications packaged as charts. It covers the chart lifecycle from scaffolding and linting through local rendering, repository or OCI distribution, and release changes against a cluster.\n\n## What It Enables\n- Scaffold charts, manage dependencies, lint or package them, and keep Kubernetes app bundles reproducible and shareable.\n- Render manifests locally with supplied values, API-version overrides, and post-renderers before touching a cluster.\n- Search, pull, verify, and push charts through chart repos or OCI registries, then install, upgrade, inspect, roll back, or uninstall releases.\n\n## Agent Fit\n- Several read paths are machine-readable: `list`, `status`, `history`, `get metadata`, `get values`, `repo list`, `search repo`, and `search hub` all support `-o json` or `-o yaml`.\n- The CLI fits inspect-change-verify loops well because templating, linting, dependency refresh, dry runs, and release operations are exposed as direct subcommands instead of an interactive UI.\n- Automation quality depends on existing kubeconfig, repository state, and registry credentials; `registry login` can be non-interactive with `--password-stdin`, but some auth paths still assume prior setup.\n\n## Caveats\n- Cluster-changing commands need Kubernetes access and enough RBAC, so the CLI is only as useful as the current context and permissions.\n- This repo's `main` branch is Helm v4 under development; the README and repo `AGENTS.md` say the current stable line is maintained on `dev-v3`.", "category": "containers", "install": "brew install helm", "github": "https:\/\/github.com\/helm\/helm", "website": "https:\/\/helm.sh\/docs\/", "source_url": null, "stars": 29589, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "helm", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "composer", "name": "Composer", "description": "PHP package manager CLI for resolving dependencies, updating lockfiles, auditing packages, and inspecting package metadata.", "long_description": "Composer is PHP's package manager for declaring dependencies, resolving version constraints, and maintaining `composer.json` and `composer.lock` in an application or library. It also exposes package search, dependency inspection, security audits, and global tool installation from the same CLI.\n\n## What It Enables\n- Add, update, remove, and lock PHP packages for a project, then install the exact dependency set in CI or production.\n- Search repositories, inspect package metadata, list outdated packages, and explain dependency or version conflicts before changing constraints.\n- Audit installed packages for vulnerabilities or abandonment, check platform requirements, and install global PHP tools or run vendored binaries and scripts.\n\n## Agent Fit\n- Commands are mostly non-interactive, support `--no-interaction` and `--working-dir`, and return stable exit codes, which fits repo automation well.\n- Real JSON output exists for `search`, `show`, `outdated`, `fund`, `licenses`, `check-platform-reqs`, and `audit`, but install and update flows are still text-first.\n- Best fit for agents already operating inside a PHP repo, where Composer becomes the inspect and change layer for dependency state and build-related scripts.\n\n## Caveats\n- `install`, `update`, `exec`, and plugin or script hooks can execute third-party code, so unattended runs need trusted inputs or flags like `--no-plugins --no-scripts`.\n- Many useful commands depend on local `composer.json` and `composer.lock` state, repository credentials, and network access, so results vary with project context.", "category": "package-managers", "install": "php -r \"copy('https:\/\/getcomposer.org\/installer', 'composer-setup.php');\" && php composer-setup.php --install-dir=\/usr\/local\/bin --filename=composer && php -r \"unlink('composer-setup.php');\"", "github": "https:\/\/github.com\/composer\/composer", "website": "https:\/\/getcomposer.org\/", "source_url": "https:\/\/getcomposer.org\/", "stars": 29333, "language": "PHP", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "tailscale", "name": "Tailscale CLI", "description": "Official Tailscale CLI for joining a tailnet, configuring a node, and inspecting or sharing services over it.", "long_description": "tailscale is the device-side CLI for joining a tailnet, configuring how a machine participates in it, and inspecting peer or connection state. It also exposes higher-level operations like Tailscale SSH, Taildrop file transfer, service publishing with `serve` or `funnel`, and a few workflow helpers such as Kubernetes kubeconfig generation.\n\n## What It Enables\n- Bring a machine onto a tailnet, change local settings such as routes, tags, exit nodes, DNS, or built-in SSH, and verify whether the node is connected.\n- Inspect peer identity and reachability with `status`, `ping`, `whois`, `ip`, `exit-node`, and `netcheck`, then use that state in follow-up shell automation.\n- Move work across the network by SSHing to peers, sending files with Taildrop, generating kubeconfig entries for Tailscale-connected clusters, or exposing local services with `serve` and `funnel`.\n\n## Agent Fit\n- The command surface is broad and mostly non-interactive once a node is installed and authenticated, which makes it useful for machine bring-up, remote access, network diagnostics, and service publishing loops.\n- Structured output is real but uneven: `status`, `up`, `whois`, `serve status`, `funnel status`, and parts of Tailnet Lock expose JSON, while many other commands remain text-first and some JSON formats are explicitly unstable.\n- Best fit is host-level automation rather than org-wide administration, because most commands act through the local `tailscaled` daemon and inherit that machine's auth, OS privileges, and connectivity.\n\n## Caveats\n- Many workflows require a running `tailscaled` daemon and sometimes root or sudo; without auth keys, initial login can open browser-driven flows.\n- `serve`, `funnel`, and some configuration paths can prompt for confirmation unless flags are prearranged, and several commands document alpha or format-stability caveats.", "category": "networking", "install": null, "github": "https:\/\/github.com\/tailscale\/tailscale", "website": "https:\/\/tailscale.com\/docs\/reference\/tailscale-cli", "source_url": null, "stars": 29168, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Tailscale" }, { "slug": "atuin", "name": "Atuin", "description": "Shell history CLI for searching, syncing, importing, and analyzing commands across terminals and machines.", "long_description": "Atuin captures shell history in a local SQLite database and adds context like directory, exit status, duration, session, and host. It is mainly a command-history tool for search, cleanup, sync, and reuse across shells and machines.\n\n## What It Enables\n- Search past commands by text, exit status, time range, directory, session, or host, then replay or insert matches from the interactive history UI.\n- Import existing history from bash, zsh, fish, Nushell, PowerShell, Xonsh, and related formats into one local history store.\n- Sync encrypted history between machines, inspect usage stats, and prune, deduplicate, or bulk-delete entries when you need to clean up noisy or sensitive history.\n\n## Agent Fit\n- Non-interactive `search` and `history list` commands support filters, custom formats, and `--print0`, so agents can query prior commands and pipe results into follow-up steps.\n- `atuin doctor` emits structured JSON, and the history model records context such as cwd, host, session, exit code, duration, author, and optional intent.\n- Fit is mixed overall: the headline experience depends on shell hooks, keybindings, and a fullscreen search UI, so unattended automation only covers part of what makes Atuin valuable.\n\n## Caveats\n- History capture depends on interactive shell integration; embedded terminals or non-interactive shells may not record commands unless they source Atuin's init hooks.\n- Sync requires an Atuin account or self-hosted server, and broad deletion commands can remove large parts of local and synced history if used carelessly.", "category": "shell-utilities", "install": "curl --proto '=https' --tlsv1.2 -LsSf https:\/\/setup.atuin.sh | sh", "github": "https:\/\/github.com\/atuinsh\/atuin", "website": "https:\/\/atuin.sh\/", "source_url": null, "stars": 28561, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": true, "source_type": "github", "vendor_name": "Atuin" }, { "slug": "logcli", "name": "logcli", "description": "Official Grafana Loki CLI for LogQL queries, live tails, label discovery, index inspection, and delete requests.", "long_description": "LogCLI is Grafana's command line client for querying Loki with LogQL and related index APIs. It is built for shell-first log work where you want to inspect, export, or administer log data without opening Grafana.\n\n## What It Enables\n- Run LogQL range and instant queries, live-tail matching streams, and export logs as raw text or JSONL.\n- Inspect label values, series cardinality, detected fields, and index volume to debug queries, label hygiene, and storage cost.\n- Download large time windows in parallel, test LogQL against local files with `--stdin`, and create, list, or cancel log deletion requests.\n\n## Agent Fit\n- Flags and `LOKI_*` environment variables make unattended auth and repeatable query windows straightforward in scripts or CI.\n- It maps closely to Loki's HTTP and websocket APIs, so agents can inspect, export, tail, and request deletions from one shell surface.\n- Structured output is partial rather than universal: log queries use JSONL, many metadata commands stay text-first, and you still need working Loki credentials or local input data.\n\n## Caveats\n- It is a query and admin client, not a log ingestion tool.\n- Grafana recommends matching the `logcli` version to the Loki server version, and some commands depend on backend features such as TSDB indexes or delete APIs.", "category": "system-monitoring", "install": null, "github": "https:\/\/github.com\/grafana\/loki", "website": "https:\/\/grafana.com\/docs\/loki\/latest\/query\/logcli\/getting-started\/", "source_url": "https:\/\/grafana.com\/loki", "stars": 27762, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Grafana" }, { "slug": "hyperfine", "name": "hyperfine", "description": "Command benchmarking CLI for comparing shell commands with statistical timing, warmups, parameter scans, and JSON exports.", "long_description": "hyperfine is a command benchmarking CLI for measuring and comparing how long shell commands take to run. It is used to test performance changes across scripts, builds, queries, and other terminal workflows without writing a custom timing harness.\n\n## What It Enables\n- Benchmark one or more shell commands with automatic run counts, warmups, and relative speed comparisons.\n- Add setup, prepare, conclude, or cleanup commands so repeated runs better match real workflows such as cold-cache tests, build steps, or short-lived services.\n- Sweep parameters and export results to JSON, CSV, or markup formats for CI regression checks, reports, and deeper analysis.\n\n## Agent Fit\n- Non-interactive flags, stable exit behavior, and `--shell=none` make it straightforward to benchmark exact commands inside scripts or agent loops.\n- `--export-json` writes structured results with summary statistics, per-run timings, exit codes, and parameter values, which makes follow-up parsing simple.\n- Best when an agent already knows which commands or variants to compare; `hyperfine` measures runtime well, but it does not profile internals or explain why something is slow.\n\n## Caveats\n- Benchmarks can be skewed by caches, shell startup, background load, or command side effects, so automation often needs warmups or explicit setup and cleanup steps.\n- It runs commands many times, which makes it a poor fit for destructive, stateful, or expensive operations unless the workflow is carefully isolated.", "category": "dev-tools", "install": "brew install hyperfine", "github": "https:\/\/github.com\/sharkdp\/hyperfine", "website": null, "source_url": null, "stars": 27662, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "vagrant", "name": "Vagrant", "description": "Official HashiCorp CLI for defining, starting, provisioning, and destroying reproducible development environments across VM and container providers.", "long_description": "Vagrant is HashiCorp's environment orchestration CLI for describing a development machine in a Vagrantfile and bringing it up on providers like VirtualBox, VMware, Hyper-V, Docker, or cloud backends. It also manages base boxes, provisioning runs, snapshots, and Vagrant Cloud publishing workflows.\n\n## What It Enables\n- Bring project-defined machines up, halt, reload, suspend, destroy, and inspect them from the shell, including global status and provider state.\n- Rebuild reproducible dev environments from boxes, run provisioners, generate SSH config, and reuse snapshots during testing or troubleshooting.\n- Search Vagrant Cloud for existing boxes and publish or manage box, provider, and version metadata for custom environments.\n\n## Agent Fit\n- Global `--machine-readable` output gives many core commands stable event lines, and `vagrant cloud search --json` adds real structured output for search results.\n- Useful when an agent needs to control local VM lifecycle or derive connection details, but most workflows orchestrate external hypervisors and long-running provisioning rather than exposing rich API-shaped data.\n- Unattended use needs care: login, confirmation prompts, provider installation, and host-specific dependencies can interrupt automation unless tokens, force flags, and prerequisites are already in place.\n\n## Caveats\n- Official installation is platform-specific via installer or package download, so a single cross-platform install command is not canonical.\n- Most high-value workflows assume an existing Vagrantfile, a working provider plugin, and access to local virtualization or container backends.", "category": "dev-tools", "install": null, "github": "https:\/\/github.com\/hashicorp\/vagrant", "website": "https:\/\/developer.hashicorp.com\/vagrant", "source_url": "https:\/\/www.vagrantup.com", "stars": 27219, "language": "Ruby", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "HashiCorp" }, { "slug": "mix", "name": "Mix", "description": "Official Elixir project CLI for generating apps, managing dependencies, compiling code, running tests, and building releases.", "long_description": "Mix is Elixir's standard project and build CLI. It is the main action surface for creating applications, resolving dependencies, compiling code, running tests, and assembling releases inside an Elixir repo.\n\n## What It Enables\n- Create new Elixir apps and umbrella projects, define project metadata in `mix.exs`, and add project-specific tasks or aliases.\n- Fetch and inspect dependencies, work with environment-specific settings, and manage project state through `mix.exs`, `mix.lock`, and task flags.\n- Compile code, run targeted or stale tests, analyze cross-file dependencies, and build deployable releases with bundled runtime scripts.\n\n## Agent Fit\n- Tasks are explicit subcommands, mostly non-interactive, and work cleanly with arguments plus environment variables such as `MIX_ENV`, `MIX_TARGET`, and `MIX_EXS`.\n- `mix help`, per-task docs, and `mix xref graph --format json --output -` give agents a learnable CLI plus a real structured inspection path, but most build and test output is still text-first.\n- Best fit for agents already operating inside an Elixir project, where Mix becomes the inspect, change, and verify layer around dependency state, compilation, tests, and releases.\n\n## Caveats\n- Mix is bundled with Elixir rather than shipped as a standalone tool, so install and behavior track the surrounding Elixir and Erlang\/OTP versions.\n- Some workflows depend on local project state, Hex availability, network access, or matching target OS and ABI when building releases.", "category": "package-managers", "install": null, "github": "https:\/\/github.com\/elixir-lang\/elixir", "website": "https:\/\/hexdocs.pm\/mix\/Mix.html", "source_url": "https:\/\/elixir-lang.org\/", "stars": 26469, "language": "Elixir", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Elixir" }, { "slug": "mise", "name": "mise", "description": "Dev environment CLI for installing tool versions, exporting project env vars, and running project tasks.", "long_description": "mise is a local dev environment CLI that combines tool version management, environment loading, and task running around hierarchical `mise.toml` config. It fits repos that want the toolchain and common commands declared once, then reused in local shells, CI, and scripted workflows.\n\n## What It Enables\n- Install and switch project toolchains like Node, Python, Go, Terraform, and other registry-backed tools from shared config files.\n- Run one-off commands or full project tasks with the resolved PATH and env using `mise exec`, `mise env`, `mise run`, and `mise tasks`.\n- Inspect active versions, config sources, env vars, and outdated tools before changing a repo or machine setup.\n\n## Agent Fit\n- Many inspection commands expose `--json`, including config, env, doctor, task, tool, version, installed tool, and outdated views.\n- `mise exec` and `mise env` let agents use the right toolchain without mutating the parent shell, which is safer than relying on prompt hooks.\n- An experimental `mise mcp` server exists for querying tools, tasks, env, and config, but the CLI plus JSON flags are the more complete automation surface today.\n\n## Caveats\n- Automatic directory switching depends on shell activation; unattended workflows should prefer `mise exec`, `mise env`, or `mise run`.\n- Commands like `mise use`, installs, trust prompts, and network-backed version resolution can change local state or require confirmation.", "category": "dev-tools", "install": "curl https:\/\/mise.run | sh", "github": "https:\/\/github.com\/jdx\/mise", "website": "https:\/\/mise.jdx.dev\/", "source_url": null, "stars": 25403, "language": "Rust", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "masscan", "name": "masscan", "description": "Internet-scale port scanner for sweeping large IP ranges, finding open ports, and collecting basic service banners.", "long_description": "masscan is an Internet-scale port scanner for sweeping large IPv4 or IPv6 ranges at high packet rates. It is built for broad exposure discovery and lightweight banner collection, not the deeper host-by-host analysis you would normally do with `nmap`.\n\n## What It Enables\n- Sweep large CIDR ranges or explicit target lists for open TCP, UDP, or other supported ports, with rate limits, excludes, and resumable config files.\n- Collect lightweight service banners from common protocols such as HTTP, SSH, TLS, SMB, RDP, and VNC after open ports are found.\n- Split wide scans across shards or adapters and export results as JSON, NDJSON, XML, grepable, binary, or simple list output for later analysis.\n\n## Agent Fit\n- The CLI is non-interactive and explicit, so it fits scripted discovery jobs where an agent needs to inspect exposed network surface area quickly.\n- Structured output is real: the source ships JSON and NDJSON writers, which makes downstream parsing and ingestion straightforward.\n- It is strongest as an inspect and verify primitive; safe use usually depends on a skill that encodes scope, exclude lists, rate caps, and follow-up handling.\n\n## Caveats\n- Banner grabbing uses `masscan`'s separate TCP\/IP stack, so source IP or port selection and host firewall rules matter if you want reliable results.\n- The tool can send traffic fast enough to disrupt networks or trigger abuse responses, so unattended runs need strict target authorization and conservative rate control.", "category": "security", "install": "brew install masscan", "github": "https:\/\/github.com\/robertdavidgraham\/masscan", "website": null, "source_url": null, "stars": 25397, "language": "C", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "infisical", "name": "Infisical CLI", "description": "Official Infisical CLI for injecting, exporting, scanning, and managing secrets from Infisical projects.", "long_description": "Infisical CLI is Infisical's command line for secret delivery and secret management from local development through CI and production. Beyond `run` and `export`, it also covers secret CRUD, leak scanning, machine-auth flows, dynamic secrets, SSH credentials, and infrastructure-facing agent or gateway commands.\n\n## What It Enables\n- Inject project secrets into app processes, export them as dotenv, JSON, or YAML, or render them into files and templates for local dev, CI jobs, and production tasks.\n- Read, set, delete, and organize secrets, folders, service tokens, and dynamic secret leases from scripts using logged-in users, service tokens, or machine identities.\n- Scan repos or staged changes for leaked secrets, install pre-commit hooks, and use SSH, PAM, agent, gateway, relay, or proxy commands to deliver credentials and controlled access.\n\n## Agent Fit\n- Structured output is real but uneven: `export --format=json`, `scan --report-format json`, `bootstrap --output json`, and shared `--output` flags on secret, folder, and dynamic-secret commands support machine parsing.\n- Once a skill standardizes `INFISICAL_TOKEN`, `--silent`, and explicit `--projectId`, `--env`, and `--path` usage, the CLI fits inspect, change, and verify loops well.\n- First-run auth still has human friction because `login` prefers browser or interactive flows, and the CLI repo itself does not expose MCP even though the broader Infisical product has separate MCP features.\n\n## Caveats\n- Most useful commands require an Infisical account plus project setup, and self-hosted or EU deployments need consistent `INFISICAL_API_URL` or `--domain` usage.\n- Commands like `agent`, `gateway`, `relay`, and `proxy` are operational components with config files and persistent processes, so they are heavier to adopt than simple one-shot secret reads.", "category": "security", "install": "brew install infisical\/get-cli\/infisical", "github": "https:\/\/github.com\/Infisical\/infisical", "website": "https:\/\/infisical.com\/docs\/cli\/overview", "source_url": null, "stars": 25278, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Infisical" }, { "slug": "gitleaks", "name": "gitleaks", "description": "Secrets scanning CLI for git history, directories, files, and stdin input.", "long_description": "Gitleaks is a secrets-scanning CLI for git history, working trees, files, and streamed input. It is built for finding hardcoded credentials before or after they land in a repo, diff, or artifact set.\n\n## What It Enables\n- Scan full git history, staged changes, pre-commit diffs, directories, files, or stdin for exposed credentials and tokens.\n- Emit JSON, CSV, JUnit, SARIF, or custom template reports for CI gates, code-scanning uploads, and follow-up parsing.\n- Use baselines, rule filters, and repo-local or explicit config files to focus scans on new leaks or organization-specific secret patterns.\n\n## Agent Fit\n- Non-interactive scan commands plus structured reports to stdout via `--report-path - --report-format json` make it workable in scripts and agent loops.\n- It fits inspect-fix-rerun workflows well: findings include file, line, rule, commit, and fingerprint data that an agent can use to patch code and verify cleanup.\n- Default console output is human-oriented and can surface matched secret text unless `--redact` and an explicit report format are set, so unattended runs need deliberate flag choices.\n\n## Caveats\n- Detection is rule-driven, so false positives and missed org-specific secrets are both possible without tuned config or follow-up review.\n- Git scans shell out through `git log -p`, and deeper archive or decode settings can make large-repo runs slower or noisier.", "category": "security", "install": "brew install gitleaks", "github": "https:\/\/github.com\/gitleaks\/gitleaks", "website": "https:\/\/gitleaks.io\/", "source_url": null, "stars": 25276, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "jenkins-cli", "name": "Jenkins CLI", "description": "Official Jenkins CLI for triggering builds, managing jobs, nodes, and plugins, and running controller administration commands.", "long_description": "Jenkins CLI is the official remote command surface for a Jenkins controller. It lets you run controller-defined commands for builds, jobs, nodes, plugins, and admin tasks from scripts or the shell.\n\n## What It Enables\n- Trigger builds, wait for completion, follow console output, and stop or safe-restart controller activity without using the web UI.\n- Read, create, and update jobs or nodes by streaming Jenkins config XML through stdout or stdin.\n- List jobs or plugins, install plugins, inspect the current identity, and run other extension-provided controller commands exposed by the server.\n\n## Agent Fit\n- Commands are mostly non-interactive and backed by stable exit codes, so they work in CI jobs and inspect or change or verify loops.\n- Transport options are practical for headless use, but output is largely plain text or XML and no native JSON mode was found.\n- Best fit when you already operate Jenkins directly and can capture controller-specific commands, permissions, and XML payloads in a skill.\n\n## Caveats\n- The available command set depends on the target controller, installed plugins, and your permissions, so discovery on one Jenkins instance may not transfer cleanly to another.\n- Many mutating workflows use Jenkins XML over stdin or stdout rather than structured JSON, which makes parsing and templated edits more brittle.", "category": "dev-tools", "install": "curl -O JENKINS_URL\/jnlpJars\/jenkins-cli.jar", "github": "https:\/\/github.com\/jenkinsci\/jenkins", "website": "https:\/\/www.jenkins.io\/doc\/book\/managing\/cli\/", "source_url": "https:\/\/www.jenkins.io\/doc\/book\/managing\/cli\/", "stars": 25081, "language": "Java", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "docs", "vendor_name": "Jenkins" }, { "slug": "vegeta", "name": "Vegeta", "description": "HTTP load testing CLI for generating controlled traffic and reporting latency, throughput, and error metrics.", "long_description": "Vegeta is a CLI and Go library for benchmarking HTTP services by sending requests at controlled rates and recording detailed results. It is built for repeatable load tests you can run locally, in CI, or across multiple workers.\n\n## What It Enables\n- Generate repeatable HTTP load against one or many endpoints from plain-text or newline-delimited JSON target definitions, with control over rate, duration, concurrency, headers, TLS, and connection behavior.\n- Capture per-request results during an attack, then convert them to JSON or CSV and compute latency, throughput, status-code, and error summaries.\n- Produce histograms, HTML latency plots, or Prometheus metrics for regression checks, capacity testing, and distributed load-test runs.\n\n## Agent Fit\n- The CLI is non-interactive and pipeline-oriented: `attack` writes results to stdout, while `encode` and `report -type=json` make downstream parsing straightforward.\n- JSON target input lets an agent generate request sets dynamically instead of hand-authoring static target files.\n- It fits request-level performance loops well, but the default attack output is gob-encoded binary and the tool does not model browser behavior, JavaScript, or multi-step user flows.\n\n## Caveats\n- Vegeta only exercises HTTP(S) traffic, so API and service benchmarking are a better fit than full end-user journey testing.\n- Load tests can create real cost or disruption; safe use still depends on a staging target, rate limits, and operator judgment.", "category": "http-apis", "install": "brew install vegeta", "github": "https:\/\/github.com\/tsenart\/vegeta", "website": null, "source_url": null, "stars": 24941, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "pulumi", "name": "Pulumi", "description": "Official Pulumi CLI for defining, previewing, deploying, importing, and managing cloud infrastructure stacks.", "long_description": "Pulumi is an infrastructure-as-code CLI and engine for defining cloud resources in general-purpose languages, previewing planned changes, and applying them to named stacks. It also manages stack configuration, secrets, imports, plugins, and Pulumi Cloud workflows from the shell.\n\n## What It Enables\n- Define cloud and Kubernetes infrastructure in TypeScript, Python, Go, .NET, Java, or YAML, preview the diff, and apply or destroy stack changes.\n- Import existing resources, refresh drifted state, inspect stack outputs or identity, and edit stack state when recovery or migration work is needed.\n- Manage stack config, secrets, plugins, templates, environments, policy packs, and Pulumi Cloud deployment or org\/project workflows from scripts or CI.\n\n## Agent Fit\n- Real `--json` support on `preview`, `up`, `import`, `stack output`, `whoami`, and `logs` makes plan, output, and metadata parsing practical.\n- It fits inspect-change-verify loops well once project code, stack selection, backend access, and cloud credentials are already in place.\n- Default workflows still lean on previews and confirmations; unattended runs usually need `--non-interactive` plus flags like `--yes` or `--skip-preview`, and `--remote` currently disables `--json`.\n\n## Caveats\n- Many operations execute the Pulumi program and provider plugins before planning, so results depend on the local project, language runtime, and credentials being set up correctly.\n- Some commands are tied to Pulumi Cloud or experimental features, so not every useful workflow is purely local or fully headless.", "category": "cloud", "install": "curl -fsSL https:\/\/get.pulumi.com\/ | sh", "github": "https:\/\/github.com\/pulumi\/pulumi", "website": "https:\/\/www.pulumi.com\/docs\/iac\/cli\/commands\/", "source_url": null, "stars": 24889, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Pulumi" }, { "slug": "ngrok", "name": "ngrok", "description": "Official ngrok CLI for exposing local HTTP, TCP, and TLS services through public tunnels with traffic inspection and endpoint controls.", "long_description": "ngrok CLI is ngrok's command line for putting local or private services behind secure public endpoints. It covers dev tunnels, webhook inspection, and more controlled HTTP, TCP, or TLS ingress with config and policy options.\n\n## What It Enables\n- Expose local web apps, webhook receivers, SSH servers, and other TCP or TLS services through public URLs or reserved addresses for testing, demos, and remote access.\n- Inspect tunneled HTTP traffic at the local web interface, replay captured webhook requests, and troubleshoot tunnel setup with built-in diagnostics.\n- Apply endpoint controls such as basic auth, OAuth or OIDC, IP allow or deny rules, header rewrites, webhook verification, and named config-driven tunnels.\n\n## Agent Fit\n- The command surface is useful in scripts when an agent needs temporary ingress into a local service, repeatable named tunnels from config, or direct access to ngrok account resources through `ngrok api`.\n- `ngrok diagnose --write-report` gives it a real JSON path, but most tunnel startup and runtime output is human-oriented status or logs rather than broadly structured command results.\n- Automation depends on account setup, auth tokens or API keys, and a running local target service, so unattended workflows work best after a skill standardizes config, tunnel names, and auth context.\n\n## Caveats\n- This entry currently points at the archived v1 repo, so the GitHub mapping needs a human correction before import.\n- Many useful commands establish a persistent tunnel process; they are less like quick inspect-and-exit utilities and more like session infrastructure that other tools or agents then use.", "category": "networking", "install": "brew install ngrok", "github": "https:\/\/github.com\/inconshreveable\/ngrok", "website": "https:\/\/ngrok.com\/docs\/agent\/cli", "source_url": null, "stars": 24472, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "ngrok", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "ngrok" }, { "slug": "difftastic", "name": "difftastic", "description": "Syntax-aware diff CLI for comparing code and directories by structure rather than raw lines.", "long_description": "difftastic is a structural diff CLI that parses supported languages and highlights syntactic changes instead of raw line churn. It can compare files, directories, and VCS diffs, with line-oriented fallback when syntax support or diff size gets in the way.\n\n## What It Enables\n- Compare two files or directories and see code changes with syntax-aware alignment that separates real edits from formatting churn.\n- Use it as an external diff for Git and other version control workflows, or inspect a file with conflict markers to view the two conflicting states.\n- Check whether edits changed syntax, ignore comments when needed, and emit JSON summaries for downstream review or verification tooling.\n\n## Agent Fit\n- `--display json` provides structured diff data, while `--exit-code` and `--check-only` make it easy to gate follow-up automation on whether syntactic changes exist.\n- It works cleanly in inspect and verify loops around generated edits because it handles files, directories, stdin, and VCS-provided temp paths without requiring an interactive session.\n- Best as a verification and review primitive rather than a mutation tool; agents can parse the summary, but the richest side-by-side output is still optimized for humans.\n\n## Caveats\n- It does not generate patches or perform merges, so it cannot be the write path for change application.\n- Unsupported languages, parse errors, or byte and graph limits can force line-oriented fallback, and the project documents performance and memory issues on large diffs.", "category": "github", "install": "brew install difftastic", "github": "https:\/\/github.com\/Wilfred\/difftastic", "website": "https:\/\/difftastic.wilfred.me.uk\/", "source_url": null, "stars": 24269, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "spotdl", "name": "spotDL", "description": "Music download CLI that matches Spotify tracks, albums, and playlists to audio sources and saves tagged files locally.", "long_description": "spotDL is a Spotify-centric music downloader that matches tracks, albums, artists, and playlists to YouTube or other configured audio providers, then saves tagged audio files locally. It also supports metadata export, playlist sync, URL lookup, and a browser-based web mode.\n\n## What It Enables\n- Download tracks, albums, playlists, artists, liked songs, and saved albums from Spotify links or search terms, with album art, lyrics, and metadata embedded in the output files.\n- Export Spotify-derived metadata and matched download URLs to `.spotdl` files or stdout, then reuse that data in later download or archive workflows.\n- Keep a local music folder in sync with a Spotify playlist or album by fetching newly added songs and removing tracks that disappeared upstream.\n\n## Agent Fit\n- Non-interactive subcommands and predictable file outputs make it workable for batch jobs that archive playlists or refresh a local music mirror.\n- `save --save-file -` provides JSON that an agent can parse, but most other commands emit human-oriented logs or plain URLs instead of structured machine output.\n- Best fit is narrow and task-specific: it works when the job is downloading or syncing music files, not as a broad media or service automation surface.\n\n## Caveats\n- Downloads come from YouTube or other configured providers rather than Spotify itself, so matches, availability, and audio quality can vary.\n- Some workflows require Spotify OAuth or cookie files, and the `web` command opens a browser-based UI instead of staying fully headless.", "category": "media", "install": "pip install spotdl", "github": "https:\/\/github.com\/spotDL\/spotify-downloader", "website": "https:\/\/spotdl.readthedocs.io\/en\/latest\/", "source_url": "https:\/\/spotdl.readthedocs.io\/en\/latest\/", "stars": 24150, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "semantic-release", "name": "semantic-release", "description": "Release automation CLI for calculating versions from commit history, generating release notes, tagging releases, and publishing from CI.", "long_description": "semantic-release is a CI-first release automation CLI that decides the next version from commit history and existing tags, then runs notes, tag, and publish steps through plugins. It fits repos that want releases to happen from merges or pushes instead of manual version bumping.\n\n## What It Enables\n- Calculate the next semantic version from analyzed commit history and the last Git tag on a release branch.\n- Generate release notes, create Git tags, and publish packages or hosted releases after CI passes.\n- Extend the pipeline with plugins or shareable configs for npm, GitHub, GitLab, or custom shell-based release steps, including non-JavaScript projects.\n\n## Agent Fit\n- Dry runs, branch rules, and non-interactive CI execution make it workable in scripted release pipelines.\n- The CLI writes human-oriented logs and rendered release notes, not a dedicated JSON output mode; structured results exist only through the JavaScript API.\n- Best for agents maintaining repo-local release config and CI credentials, not for ad hoc exploratory shell tasks.\n\n## Caveats\n- Publishing depends on correct Git tags, release-branch setup, and host or registry credentials in the environment.\n- Most real behavior comes from configured plugins, so capability varies by project rather than by the base command alone.", "category": "dev-tools", "install": "npx semantic-release", "github": "https:\/\/github.com\/semantic-release\/semantic-release", "website": "https:\/\/semantic-release.gitbook.io\/semantic-release\/", "source_url": null, "stars": 23398, "language": "JavaScript", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "d2", "name": "D2", "description": "Diagram-as-code CLI for rendering D2 files to SVG, PNG, PDF, PowerPoint, GIF, or text.", "long_description": "D2 is a diagram-as-code CLI and language for turning text files into rendered diagrams. It fits documentation, architecture, and presentation workflows where diagrams should live in version control and be generated on demand.\n\n## What It Enables\n- Render `.d2` source into SVG, PNG, PDF, PowerPoint, GIF, or plain-text diagram output from local files, stdin, or scripted build steps.\n- Format and validate diagram source, list themes and layout engines, and switch rendering options without hand-editing visual assets.\n- Run live preview loops with `--watch` or send a diagram to the hosted playground when iterating on docs, architecture diagrams, slides, or embedded site assets.\n\n## Agent Fit\n- Render, `fmt`, and `validate` flows are explicit non-interactive commands, and stdin or stdout support makes them easy to wrap in content-generation or CI pipelines.\n- Machine-readable output is limited: the public CLI mainly emits rendered artifacts and text, and the repo does not expose a documented JSON mode for normal automation.\n- Best fit is generating and checking versioned diagram artifacts inside documentation or design workflows, not inspecting remote service state or driving operational control loops.\n\n## Caveats\n- `--watch` and `play` open browser-based preview flows, so those paths are less useful in fully headless environments.\n- PNG, PDF, PPTX, and GIF exports rely on browser rendering support, and extra layout plugins may come from separate `d2plugin-*` binaries on `$PATH`.", "category": "dev-tools", "install": "curl -fsSL https:\/\/d2lang.com\/install.sh | sh -s --", "github": "https:\/\/github.com\/terrastruct\/d2", "website": "https:\/\/d2lang.com\/", "source_url": null, "stars": 23186, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Terrastruct" }, { "slug": "gum", "name": "Gum", "description": "Shell scripting UI CLI for prompts, selectors, spinners, styled output, and lightweight terminal formatting.", "long_description": "Gum is a shell scripting UI toolkit packaged as one CLI, with commands for prompts, selectors, file pickers, spinners, tables, styling, and text formatting. It helps turn plain shell scripts into guided terminal workflows without building a custom TUI in Go.\n\n## What It Enables\n- Prompt for short or multi-line input, confirmations, file choices, and single- or multi-select menus, then capture the result on stdout or in exit codes.\n- Wrap existing shell commands with spinners, pagers, tables, and styled or joined text so scripts can guide a user through a workflow.\n- Build human-in-the-loop helpers such as commit message wizards, Git branch cleanup, package removal menus, or tmux and editor pickers.\n\n## Agent Fit\n- Commands compose with the shell through stdout, stderr, and exit codes, which is enough for simple wrappers and operator-facing scripts.\n- Structured output exists only on `gum log --formatter json`; the main selection and prompt commands return plain text or exit codes.\n- Useful when an agent is generating or driving a human-facing terminal workflow; weak when the goal is unattended inspection or direct service control.\n\n## Caveats\n- Many high-value commands require a real terminal and user input, so they are awkward in CI or fully headless runs.\n- The CLI does not talk to external services itself; it is mainly a UX layer around other commands and shell logic.", "category": "shell-utilities", "install": "brew install gum", "github": "https:\/\/github.com\/charmbracelet\/gum", "website": null, "source_url": null, "stars": 23071, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": true, "source_type": "github", "vendor_name": "Charmbracelet" }, { "slug": "charm", "name": "charm", "description": "Shell UI CLI for adding prompts, pickers, spinners, styling, and logs to shell scripts.", "long_description": "Gum is a shell UI CLI that packages prompts, selectors, spinners, styling, and lightweight formatting helpers as subcommands for shell scripts and aliases. It is most useful when you want a human-friendly terminal flow around an existing script, not when you need a service API client or headless automation primitive.\n\n## What It Enables\n- Add confirms, text inputs, choosers, fuzzy filters, file pickers, and multi-line editors to shell scripts, returning selections on stdout or via exit codes.\n- Wrap long-running commands with spinners, styled logs, formatted markdown or code output, tables, and joined layouts for terminal-facing workflows.\n- Build lightweight interactive helpers for tasks like writing commit messages, selecting branches or packages, opening files, and reviewing long text in the terminal.\n\n## Agent Fit\n- Commands compose through stdin, stdout, and exit codes, and `gum log` can emit JSON with `--formatter json` for structured log output.\n- Most high-value commands open Bubble Tea TUIs and expect a human at the keyboard, so unattended agent use is limited.\n- Best fit as a UX layer for scripts a person will run or supervise; weaker as a direct inspect or change primitive for autonomous agents.\n\n## Caveats\n- Many commands need a real TTY; in CI or non-interactive shells they either fail or lose most of their value.\n- Structured output support is narrow; outside `gum log`, outputs are usually plain text selections or styled terminal content.", "category": "dev-tools", "install": "brew install gum", "github": "https:\/\/github.com\/charmbracelet\/gum", "website": null, "source_url": null, "stars": 23071, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": true, "source_type": "github", "vendor_name": "Charm" }, { "slug": "cloc", "name": "cloc", "description": "Count blank, comment, and code lines across files, directories, archives, and git revisions.", "long_description": "cloc is a source code line counter for files, directories, archives, and git revisions. It reports blank, comment, and code lines by language and can also diff two snapshots of a codebase.\n\n## What It Enables\n- Measure language mix and code volume across a repo, directory tree, archive, or checked-out project.\n- Compare two commits, branches, directories, or archives to see how blank, comment, and code counts changed.\n- Generate per-file, JSON, XML, YAML, or SQL reports for audits, trend tracking, or downstream analysis.\n\n## Agent Fit\n- Non-interactive flags, deterministic report modes, and support for file lists or VCS-backed inputs make it easy to drop into scripts and CI checks.\n- JSON output is real and easy to parse, and `--by-file`, `--diff`, and `--vcs git` expose useful inspection surfaces for repo analysis loops.\n- It is inspection-only: useful for audits, sizing, and change analysis, but it does not modify repos or understand code semantics beyond comment heuristics.\n\n## Caveats\n- Counts are heuristic rather than parser-based, so embedded languages, comment markers inside strings, and docstrings can skew results.\n- Some archive and VCS workflows depend on external tools like `git`, `rpm2cpio`, or `dpkg-deb` being available.", "category": "dev-tools", "install": "brew install cloc", "github": "https:\/\/github.com\/AlDanial\/cloc", "website": null, "source_url": "https:\/\/github.com\/AlDanial\/cloc", "stars": 22644, "language": "Perl", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "jaeger", "name": "Jaeger tooling", "description": "Distributed tracing backend and utility suite for running Jaeger, generating traces, and operating Jaeger storage.", "long_description": "Jaeger tooling is the Jaeger project's suite of binaries for running the tracing backend and handling related storage or test-traffic tasks. The main `jaeger` binary starts a config-driven backend, while companion tools cover trace generation and storage operations.\n\n## What It Enables\n- Start an all-in-one or config-driven Jaeger backend that exposes the UI, query APIs, remote sampling, and the built-in MCP extension.\n- Generate steady trace traffic with `tracegen` for pipeline testing, sampling checks, and performance tuning.\n- Run storage-side maintenance with `jaeger-remote-storage`, `jaeger-es-rollover`, and `jaeger-es-index-cleaner` when operating Jaeger deployments.\n\n## Agent Fit\n- The binaries are non-interactive and config-driven, so starting services, checking health, printing config, and running storage maintenance fit scripts and CI well.\n- Direct CLI inspection is limited; most real trace analysis happens through the HTTP query API, UI, or MCP endpoint rather than structured terminal output.\n- Built-in MCP support is useful for agent drill-down, but it is exposed over HTTP and depends on a running Jaeger query service.\n\n## Caveats\n- This is a multi-binary suite rather than a single focused client CLI, so the entry is broader and less discoverable than tools with one command surface.\n- The recommended quick start is container-first and YAML-config driven, which is heavier than typical terminal-first admin or query CLIs.", "category": "system-monitoring", "install": "docker run --rm --name jaeger -p 16686:16686 -p 4317:4317 -p 4318:4318 jaegertracing\/jaeger:latest", "github": "https:\/\/github.com\/jaegertracing\/jaeger", "website": "https:\/\/www.jaegertracing.io\/docs\/latest\/getting-started\/", "source_url": "https:\/\/www.jaegertracing.io\/docs\/", "stars": 22543, "language": "Go", "has_mcp": true, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "svgo", "name": "SVGO", "description": "SVG optimization CLI for removing editor metadata, simplifying markup, and applying configurable cleanup plugins.", "long_description": "SVGO is a CLI and library for optimizing SVG files by removing editor cruft, simplifying markup, and applying configurable transformation plugins. It fits asset pipelines and repository cleanup work where you need smaller or more normalized SVG output before shipping files.\n\n## What It Enables\n- Optimize a single SVG, a whole folder tree, stdin input, or an inline SVG string, then write the result to files, folders, or stdout.\n- Apply project-specific cleanup rules through `svgo.config.*`, including default-preset overrides and custom plugins.\n- Normalize exported SVG assets for web delivery, design-system repos, or build steps before committing, bundling, or publishing them.\n\n## Agent Fit\n- Non-interactive flags, stdin\/stdout support, and recursive folder mode make it easy to slot into scripts, CI, or agent-driven asset cleanup loops.\n- There is no JSON or structured report mode; the machine-readable result is the optimized SVG itself, while status output stays human-oriented.\n- Best for explicit local transformations where the target files and desired plugin config are already known.\n\n## Caveats\n- If you omit `-o`, the CLI rewrites the input files in place.\n- Optimization behavior depends on plugin choices, so preserving IDs, `viewBox`, or editor-specific data may require config changes.", "category": "dev-tools", "install": "npm install -g svgo", "github": "https:\/\/github.com\/svg\/svgo", "website": "https:\/\/svgo.dev\/", "source_url": null, "stars": 22359, "language": "JavaScript", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "argocd", "name": "Argo CD CLI", "description": "GitOps CLI for inspecting, diffing, syncing, and managing Argo CD applications, projects, clusters, and repos.", "long_description": "argocd is the command line client for Argo CD, a GitOps continuous delivery system for Kubernetes. It lets you inspect application state, compare desired versus live resources, trigger syncs, and administer the clusters, repos, and projects Argo CD manages.\n\n## What It Enables\n- Inspect applications, manifests, resource trees, logs, history, sync status, and health, then wait for specific sync or health conditions from scripts.\n- Diff live versus target state, trigger syncs or rollbacks, patch or delete app resources, and scope operations to selected resources, labels, revisions, or local manifests.\n- Manage the surrounding control plane by listing or updating clusters, repositories, projects, accounts, certificates, and other Argo CD configuration from the terminal.\n\n## Agent Fit\n- Many read paths support `-o json`, so application, repository, cluster, project, account, and version data can be parsed directly in shell or CI workflows.\n- Automation fit is strong because commands are mostly non-interactive once auth is in place, and operations like `app diff`, `app sync`, and `app wait` expose flags and exit behavior that suit inspect-change-verify loops.\n- It is most useful for agents that already operate inside a Kubernetes or GitOps environment; `--core` broadens that fit by allowing direct Kubernetes-backed operation when a full Argo CD API server is not the control point.\n\n## Caveats\n- Useful operation depends on a reachable Argo CD deployment or enough Kubernetes RBAC for `--core`, plus preconfigured auth, context, and cluster access.\n- Some flows still assume a human, especially `login --sso`, browser-based auth, and sync previews or prompts unless you choose non-interactive flags.", "category": "containers", "install": "brew install argocd", "github": "https:\/\/github.com\/argoproj\/argo-cd", "website": "https:\/\/argo-cd.readthedocs.io\/en\/stable\/user-guide\/commands\/argocd\/", "source_url": "https:\/\/argo-cd.readthedocs.io\/en\/stable\/cli_installation\/", "stars": 22254, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Argo Project" }, { "slug": "localtunnel", "name": "localtunnel", "description": "CLI for exposing a local port through a public URL for webhook testing, demos, and remote access.", "long_description": "localtunnel creates a public URL that forwards requests to a port on your machine or another local host. It is mainly for testing callbacks, sharing in-progress local services, or giving external tools a temporary endpoint without deploying first.\n\n## What It Enables\n- Expose a local dev server or webhook receiver on a public HTTPS URL for callback testing, demos, and remote QA.\n- Request a named subdomain or point at a compatible custom tunnel server when you need a predictable endpoint or self-hosted relay.\n- Proxy to a non-default local host or local HTTPS service and optionally print incoming request paths while the tunnel runs.\n\n## Agent Fit\n- The command surface is small and non-interactive once configured, so an agent can start a tunnel with a few flags and capture the emitted URL for follow-up steps.\n- Automation has to parse stdout because the URL and request activity are plain text rather than structured JSON.\n- Best for short-lived dev workflows where a skill can start the tunnel, hand the public URL to another system, then stop the process after verification.\n\n## Caveats\n- The default flow depends on the hosted `localtunnel.me` relay or another compatible server passed with `--host`.\n- This CLI mainly opens and maintains a tunnel; it does not provide richer access controls, persistent resource management, or broad inspection commands.", "category": "networking", "install": "npm install -g localtunnel", "github": "https:\/\/github.com\/localtunnel\/localtunnel", "website": "https:\/\/localtunnel.me", "source_url": null, "stars": 22122, "language": "JavaScript", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "age", "name": "age", "description": "File encryption CLI for encrypting and decrypting files with public keys, SSH keys, or passphrases.", "long_description": "age is a file encryption CLI and format for encrypting files or stdin streams with explicit recipients instead of config-heavy key management. The project also ships `age-keygen` for native key generation and `age-inspect` for reading file metadata without decrypting.\n\n## What It Enables\n- Encrypt files or piped data to one or more recipients, recipients files, SSH public keys, or a passphrase, then decrypt them from scripts or shell pipelines.\n- Generate native X25519 or post-quantum hybrid key pairs and derive shareable recipient strings from identity files.\n- Inspect encrypted files without decryption to see recipient stanza types, armor status, post-quantum usage, and size breakdowns; `age-inspect --json` supports scripting.\n\n## Agent Fit\n- The main commands are non-TUI, stdin\/stdout-oriented, and explicit about inputs, outputs, recipients, and identities, so they compose cleanly in shell workflows.\n- Structured output exists for inspection via `age-inspect --json`, but the main encrypt and decrypt path mostly streams bytes and human-readable errors rather than rich machine-readable state.\n- Works well as a local primitive for protecting artifacts, secrets, or handoff files inside a larger workflow; less useful as a broad service-control surface.\n\n## Caveats\n- Passphrase entry, password-protected SSH keys, and some plugin flows require terminal interaction, which limits unattended use.\n- JSON support is limited to `age-inspect`; `age` and `age-keygen` do not expose comparable structured output modes.", "category": "security", "install": "brew install age", "github": "https:\/\/github.com\/FiloSottile\/age", "website": "https:\/\/age-encryption.org", "source_url": null, "stars": 21567, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "nnn", "name": "nnn", "description": "Terminal file manager for browsing directories, picking files, and running file actions or plugins from the shell.", "long_description": "nnn is a fullscreen terminal file manager for browsing local directories, selecting files, and triggering file actions or plugins from one keyboard-driven interface. It also exposes picker and shell-handoff paths that let scripts feed in candidate files or capture the resulting selection.\n\n## What It Enables\n- Browse directory trees, filter and sort entries, inspect file details, and perform copy, move, rename, delete, archive, and open workflows from one terminal UI.\n- Feed a scripted list of NUL-separated paths on stdin, then pick one or more results back out to stdout or a file with `-p` for shell wrappers and editor integrations.\n- Trigger plugins or shell commands against hovered or selected files for previews, diffs, uploads, mounts, clipboard actions, and other local file tasks.\n\n## Agent Fit\n- It can participate in inspect-select-act loops through stdin listings, picker output, `NNN_TMPFILE` quit-to-cd integration, and `NNN_FIFO` notifications for the hovered path.\n- Exported state is plain text or NUL-delimited paths, and most useful actions still happen inside the fullscreen TUI rather than stable non-interactive subcommands.\n- Best fit is a shared human-agent file workspace or interactive picker, not a headless replacement for core shell file utilities.\n\n## Caveats\n- Plugin power depends on external tools and trusted scripts; many bundled plugins are wrappers around other CLIs.\n- Most functionality assumes an interactive terminal session, and there is no JSON output mode for unattended parsing.", "category": "file-management", "install": "brew install nnn", "github": "https:\/\/github.com\/jarun\/nnn", "website": "https:\/\/github.com\/jarun\/nnn\/wiki", "source_url": null, "stars": 21367, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "sops", "name": "sops", "description": "Secrets file CLI for encrypting, decrypting, rotating, and editing YAML, JSON, dotenv, INI, and binary files with age, PGP, Vault, or cloud KMS keys.", "long_description": "sops manages secrets stored in regular files by encrypting the sensitive values while keeping surrounding YAML, JSON, dotenv, or INI structure intact. It supports age, PGP, Vault transit, and several cloud KMS backends, so teams can keep secrets in Git and still operate on them from the shell.\n\n## What It Enables\n- Encrypt and decrypt structured secret files without flattening them into a separate secrets store, so they remain reviewable and versionable.\n- Rotate data keys, add or remove recipients, and update key groups across existing files with `rotate`, `updatekeys`, and `.sops.yaml` rules.\n- Set or unset specific document paths, inject decrypted values into subprocess environments or temp files, and publish re-encrypted material to S3, GCS, or Vault.\n\n## Agent Fit\n- Core commands take explicit files, stdin\/stdout, and flags, so `decrypt`, `set`, `unset`, `rotate`, `updatekeys`, and the exec helpers fit shell scripts and CI well.\n- Machine-readable output exists, but it is limited: `filestatus` emits JSON while most other commands return file contents or human-oriented errors.\n- Best as a local secrets primitive inside a larger workflow, especially when a skill supplies the right key sources, paths, and `.sops.yaml` conventions.\n\n## Caveats\n- Many useful flows depend on external credentials or local key material for age, PGP, Vault, or cloud KMS backends.\n- `sops edit` is editor-driven and some key-update flows prompt unless you opt into non-interactive flags, so unattended automation should stick to the non-interactive subcommands.", "category": "security", "install": "brew install sops", "github": "https:\/\/github.com\/getsops\/sops", "website": "https:\/\/getsops.io\/", "source_url": null, "stars": 21096, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "fx", "name": "fx", "description": "Interactive JSON viewer and JavaScript processor for exploring, transforming, and editing JSON in the terminal.", "long_description": "fx is a JSON-first terminal tool with two modes: a fullscreen viewer for browsing documents and a JavaScript-powered processor for transforming data from stdin or files. It can also parse YAML or TOML input and route it through the same workflow.\n\n## What It Enables\n- Browse nested JSON, search keys or values, collapse sections, preview nodes, and print selected paths or values from a terminal viewer.\n- Pipe JSON streams through JavaScript expressions to extract fields, map or filter arrays, slurp multiple objects, or process raw text lines.\n- Edit JSON files in place with expression chains and the built-in `save` function, or ingest YAML and TOML and emit JSON for later steps.\n\n## Agent Fit\n- Expression mode reads stdin or files, writes results to stdout, and returns non-zero exits on parse or JavaScript errors, which suits inspect and transform loops.\n- Structured output is native here: object and array results are emitted as pretty JSON, while scalar values print directly for shell composition.\n- The fullscreen viewer is useful for human debugging, but unattended agents should usually call explicit expressions and treat the TUI as optional exploration.\n\n## Caveats\n- The transformation language is JavaScript-flavored rather than `jq` syntax, so automation often needs a quick docs or `--help` pass before first use.\n- In-place edits require a real file path and the special `save` function; that path is unavailable on stdin and symbolic links are refused.", "category": "data-processing", "install": "brew install fx", "github": "https:\/\/github.com\/antonmedv\/fx", "website": "https:\/\/fx.wtf\/", "source_url": null, "stars": 20317, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "psql", "name": "psql", "description": "Official PostgreSQL terminal for running SQL, inspecting schema objects, importing or exporting data, and scripting database admin tasks.", "long_description": "psql is PostgreSQL's official command-line client for interactive SQL, batch execution, and database introspection. It covers day-to-day querying plus admin and data movement tasks without requiring a separate GUI.\n\n## What It Enables\n- Run ad hoc SQL or script files against PostgreSQL, including variable-driven scripts and single-transaction batch runs for repeatable admin work.\n- Inspect databases, schemas, tables, indexes, roles, and server settings with `\\d`-style meta-commands and hidden-query debugging via `-E`.\n- Import or export data and chain follow-up shell steps with `\\copy`, output redirection, `\\gset`, and repeated query execution through `\\watch`.\n\n## Agent Fit\n- `-c`, `-f`, stdin, `-X`, `-v`, and documented exit codes make it reliable in scripts, CI jobs, and inspect or change or verify loops.\n- No native JSON flag is built in, so automation usually relies on SQL-generated JSON or text and CSV modes such as `--csv`, `-A`, `-t`, and custom separators.\n- Strong fit when an agent already has database connectivity and enough schema context to issue direct SQL instead of going through a higher-level API.\n\n## Caveats\n- You need working PostgreSQL credentials and network access first, and many useful workflows still depend on knowing the target schema well enough to write safe SQL.\n- Default interactive behavior and user `~\/.psqlrc` settings can affect output or prompts, so unattended runs should use `-X` and explicit formatting flags.", "category": "databases", "install": "brew install libpq", "github": "https:\/\/github.com\/postgres\/postgres", "website": "https:\/\/www.postgresql.org\/docs\/current\/app-psql.html", "source_url": "https:\/\/www.postgresql.org\/docs\/current\/app-psql.html", "stars": 20255, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "PostgreSQL" }, { "slug": "hey", "name": "hey", "description": "HTTP load-testing CLI for sending concurrent requests to a URL and measuring latency, throughput, and status codes.", "long_description": "hey is a small HTTP load generator for benchmarking a web endpoint from the shell. It sends concurrent requests to one URL and summarizes how that endpoint responds under pressure.\n\n## What It Enables\n- Run quick load tests against an HTTP or HTTP\/2 endpoint by request count or duration to gauge latency, throughput, and failure rates.\n- Exercise specific request shapes with custom methods, headers, body data, basic auth, host overrides, proxy settings, and transport toggles such as disabled redirects or keep-alives.\n- Export per-request timing and status-code data as CSV for spreadsheet analysis or follow-up parsing after a benchmark run.\n\n## Agent Fit\n- The flag surface is non-interactive and predictable, so agents can use it in CI, deploy verification, or repeatable benchmark scripts without extra prompts.\n- Automation is weaker than tools with native JSON because the documented machine-readable output is CSV and the default report is human-oriented.\n- Best fit for lightweight inspect-and-verify performance checks against a single URL rather than broad service management or root-cause diagnosis.\n\n## Caveats\n- It focuses on one-target HTTP load generation; agents need other tools for distributed testing, tracing, or deeper performance debugging.\n- CSV is the only documented structured output mode, so automated thresholds usually need a parsing step before follow-up decisions.", "category": "http-apis", "install": "brew install hey", "github": "https:\/\/github.com\/rakyll\/hey", "website": null, "source_url": null, "stars": 19806, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "kubectx", "name": "kubectx", "description": "Kubernetes context-switching CLI for listing, selecting, renaming, deleting, and changing the active `kubectl` context.", "long_description": "kubectx is a small Kubernetes workflow CLI for changing the active `kubectl` context without repetitive `kubectl config` commands. It also lets you inspect, rename, delete, and unset context entries in kubeconfig.\n\n## What It Enables\n- List available kubeconfig contexts and print the current one before running cluster-specific commands.\n- Switch to another context, or jump back to the previous one, by updating the active `kubectl` context.\n- Rename, delete, or unset context entries when cleaning up kubeconfig state across many clusters.\n\n## Agent Fit\n- Useful as a thin shell primitive because the normal commands are short, non-interactive, and return clear success or failure states.\n- Automation fit is limited by plain text output and global kubeconfig mutation, so agents need follow-up `kubectl` checks to verify state.\n- Optional `fzf` selection helps humans, but unattended workflows should stick to explicit context names and `--current` reads.\n\n## Caveats\n- It manages kubeconfig context state only; namespace switching lives in the companion `kubens` command.\n- There is no JSON or dry-run mode, so scripts must parse simple text or inspect kubeconfig separately.", "category": "containers", "install": "brew install kubectx", "github": "https:\/\/github.com\/ahmetb\/kubectx", "website": null, "source_url": null, "stars": 19515, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": "kubernetes", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "vhs", "name": "VHS", "description": "CLI for scripting terminal recordings into GIF, video, screenshot, or text snapshot outputs with `.tape` files.", "long_description": "VHS is a terminal recording CLI built around `.tape` scripts that replay typed input and waits into rendered artifacts. It covers demo capture, terminal screenshots and videos, and text snapshot generation for testing.\n\n## What It Enables\n- Render scripted terminal demos into GIF, WebM, MP4, PNG frame, or screenshot outputs from a repeatable `.tape` file.\n- Record a live shell session into a starter tape, then edit or validate it before rerendering for docs, release notes, or tutorials.\n- Capture `.txt` or `.ascii` terminal snapshots for golden-file testing, or render remotely over SSH on a host that already has the needed commands installed.\n\n## Agent Fit\n- Tape files, stdin input, and `validate` make render runs deterministic enough for CI, doc-generation pipelines, and retryable agent workflows.\n- The automation surface is file-oriented rather than machine-readable: VHS emits media or text artifacts plus logs, with no JSON mode for downstream parsing.\n- Best fit when an agent needs to package or verify terminal behavior visually; it is much less useful as a live control layer for inspecting or mutating external systems.\n\n## Caveats\n- Rendering requires `ttyd` and `ffmpeg` on PATH, and the render host also needs the commands being demonstrated.\n- Tapes effectively script shell input, and `publish` uploads GIFs to `vhs.charm.sh`, so untrusted cassettes or automatic sharing need care.", "category": "media", "install": "brew install vhs", "github": "https:\/\/github.com\/charmbracelet\/vhs", "website": null, "source_url": null, "stars": 18875, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Charm" }, { "slug": "hurl", "name": "Hurl", "description": "Run and test HTTP requests defined in a simple plain text format.", "long_description": "Run and test HTTP requests defined in a simple plain text format.\n\n## Highlights\n- Installs with `brew install hurl`\n- Supports structured JSON or NDJSON output for machine-readable automation\n- Primary implementation language is Rust\n\n## Agent Fit\n- Fits shell scripts and agent workflows that need a terminal-native interface\n- Machine-readable output makes it easier to inspect results, branch logic, and chain follow-up commands\n- Straightforward installation helps bootstrap local or ephemeral automation environments\n\n## Caveats\n- Real use depends on configuring credentials or service access before commands become useful", "category": "http-apis", "install": "brew install hurl", "github": "https:\/\/github.com\/Orange-OpenSource\/hurl", "website": "https:\/\/hurl.dev\/", "source_url": null, "stars": 18607, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "gradle", "name": "Gradle", "description": "Build automation CLI for running tasks, resolving dependencies, testing code, and publishing artifacts in JVM and polyglot projects.", "long_description": "Gradle is a build automation CLI that executes project-defined tasks and ships built-in commands for dependency inspection, reporting, wrapper management, and build initialization. It is used to build, test, package, and publish software across Java, Kotlin, Android, native, and other polyglot projects.\n\n## What It Enables\n- Run project build, test, lint, packaging, and publishing tasks from the terminal, including multi-project builds through task selectors and project paths.\n- Inspect project structure, task availability, properties, dependency graphs, selected versions, outgoing variants, and resolvable configurations before changing build logic.\n- Initialize new builds, generate or update the Gradle Wrapper, and control execution with dry runs, build cache, configuration cache, parallelism, continuous mode, and daemon flags.\n\n## Agent Fit\n- Commands are explicit, mostly non-interactive, and built around task names, flags, exit codes, and project directories, which fits CI and agent loops well.\n- Inspection is strong, but most built-in output is plain text or HTML reports rather than JSON, so follow-up parsing is less reliable than with more machine-oriented CLIs.\n- Best fit when an agent already has repo context and can drive `gradlew` inside a specific project; usefulness drops outside a concrete build with known tasks and plugins.\n\n## Caveats\n- Most useful actions depend on repository-local build scripts, plugins, credentials, and JDK or toolchain setup, so behavior varies sharply across projects.\n- Runs can start daemons, download distributions through the wrapper, and execute project or plugin code, which adds side effects and trust concerns for unattended use.", "category": "package-managers", "install": "sdk install gradle", "github": "https:\/\/github.com\/gradle\/gradle", "website": "https:\/\/docs.gradle.org\/current\/userguide\/userguide.html", "source_url": "https:\/\/gradle.org", "stars": 18419, "language": "Java", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Gradle" }, { "slug": "git-extras", "name": "git-extras", "description": "Git utility bundle for repo summaries, author stats, changelogs, releases, and batch repo operations.", "long_description": "git-extras is a collection of additional Git subcommands for inspecting repository history and automating common maintenance tasks. It is most useful when plain `git` leaves you stitching together ad hoc shell pipelines for reports, releases, or repetitive repo cleanup.\n\n## What It Enables\n- Summarize repository age, branch activity, authorship, and file-level effort across a repo or a selected path.\n- Generate changelogs, create release commits and tags, and clean up merged or squashed branches with higher-level Git helpers.\n- Run Git commands across registered workspaces, open repository URLs, and handle repetitive branch or remote housekeeping from the shell.\n\n## Agent Fit\n- The commands are regular shell subcommands with stable flags and exit behavior, so agents can call focused helpers instead of rebuilding every workflow from raw `git` plumbing.\n- Most output is plain text tables or browser-oriented behavior rather than machine-readable JSON, which makes downstream parsing and verification weaker than purpose-built API CLIs.\n- Best fit is local repo maintenance and reporting loops where a skill can standardize a handful of subcommands; it is less compelling as a universal interface to remote Git hosting.\n\n## Caveats\n- There is no real structured output mode in the inspected commands, and several helpers depend on Unix utilities such as `awk`, `column`, `curl`, `ps`, or `rsync`.\n- Some commands remain human-oriented, including browser launchers and GitHub pull request creation that can prompt for credentials or two-factor codes.", "category": "github", "install": "brew install git-extras", "github": "https:\/\/github.com\/tj\/git-extras", "website": null, "source_url": null, "stars": 17996, "language": "Shell", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "gallery-dl", "name": "gallery-dl", "description": "Media download CLI for fetching images, videos, and metadata from supported gallery, creator, and social media URLs.", "long_description": "gallery-dl is a URL-driven downloader for pulling media and metadata from a large catalog of supported sites, including galleries, creator pages, boards, posts, and collections. It is built around extractor modules and deep configuration rather than a human-first interactive flow.\n\n## What It Enables\n- Download images, videos, and attached metadata from supported gallery, creator, forum, and social media URLs.\n- Queue URLs from stdin or files, filter by ranges, dates, tags, or custom expressions, and keep state with archives and cache files.\n- Extract direct file URLs or structured metadata without downloading, then feed the results into other shell tools.\n\n## Agent Fit\n- Non-interactive flags, input-file support, and config-driven authentication make it workable in unattended batch jobs.\n- Real structured output exists via `-j\/--dump-json`, `-J\/--resolve-json`, and optional JSON Lines mode for downstream parsing.\n- Fit is mixed by site-specific extractor reliability: protected sources often need cookies or browser state, and upstream site changes can break workflows.\n\n## Caveats\n- Some video and conversion flows depend on extra tools such as `yt-dlp`, `ffmpeg`, or `mkvmerge`.\n- Support is extractor-by-extractor, so coverage and stability vary by site.", "category": "media", "install": "python3 -m pip install -U gallery-dl", "github": "https:\/\/github.com\/mikf\/gallery-dl", "website": "https:\/\/gdl-org.github.io\/docs\/", "source_url": "https:\/\/github.com\/mikf\/gallery-dl", "stars": 17094, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "asciinema", "name": "asciinema", "description": "Terminal session recording CLI for capturing, replaying, streaming, and sharing shell sessions as asciicast text logs.", "long_description": "asciinema records terminal sessions into the asciicast format and can also replay, stream, convert, concatenate, and upload those recordings. It is mainly a capture-and-sharing tool for shell workflows rather than a general service administration CLI.\n\n## What It Enables\n- Record a shell command or full session to asciicast, raw terminal output, or plain text, including unattended runs with `--headless`.\n- Stream a live terminal session over a local HTTP server or an asciinema server, then upload recordings for sharing or documentation.\n- Concatenate recordings and convert between asciicast v1 or v2 or v3, raw output, and plain text for docs, demos, or regression artifacts.\n\n## Agent Fit\n- `--headless` and `--return` make it usable in scripted runs where an agent needs to capture terminal behavior and preserve the wrapped command's exit status.\n- Structured asciicast v2 or v3 output can be written to files or stdout, which gives agents a machine-readable artifact to parse, store, or post-process.\n- Best for documentation, demos, bug repros, and audit trails; it is less useful as a direct inspect-or-mutate primitive against external systems.\n\n## Caveats\n- Remote upload and public streaming depend on browser-based authentication and an asciinema server account or self-hosted deployment.\n- Playback and the local stream viewer are human-facing experiences, so much of the value comes after the capture step rather than during autonomous execution.", "category": "dev-tools", "install": "cargo install --locked --git https:\/\/github.com\/asciinema\/asciinema", "github": "https:\/\/github.com\/asciinema\/asciinema", "website": "https:\/\/asciinema.org", "source_url": null, "stars": 16938, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "asciinema", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "asciinema" }, { "slug": "aws-cli", "name": "AWS CLI", "description": "Official AWS CLI for inspecting and managing AWS services, S3 transfers, CloudFormation deployments, and credential workflows.", "long_description": "AWS CLI is AWS's official command line for calling service APIs and running higher-level workflows like S3 sync, CloudFormation deploy, log tailing, and credential management. The canonical repo currently defaults to CLI v1, but current AWS CLI releases and docs live on the v2 branch.\n\n## What It Enables\n- Inspect and mutate resources across AWS services from the shell, with profile, region, pagination, and JMESPath query controls.\n- Sync files to and from S3, deploy CloudFormation stacks, tail CloudWatch Logs, and use other high-level service helpers without writing raw API calls.\n- Configure access keys, SSO sessions, login profiles, exported credentials, and optional command history for repeatable local or CI workflows.\n\n## Agent Fit\n- Structured `--output json` plus `--query` filtering make it easy to feed results into scripts, CI steps, and inspect\/change\/verify loops.\n- Most commands are non-interactive and composable, but setup helpers such as `aws configure`, `configure sso`, `login`, and wizard-style flows can prompt or open a browser.\n- No native MCP or packaged skills tree; the main wrinkle is that this repo's default branch is CLI v1 while current production guidance is AWS CLI v2.\n\n## Caveats\n- The checked-out default branch is AWS CLI v1 and the README announces v1 maintenance mode starting July 15, 2026; current v2 source lives on the `v2` branch.\n- Official v2 installation is platform-specific, so a single cross-platform install command is not a good fit for this entry.", "category": "cloud", "install": null, "github": "https:\/\/github.com\/aws\/aws-cli", "website": "https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/", "source_url": "https:\/\/aws.amazon.com\/cli\/", "stars": 16799, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "AWS" }, { "slug": "zola", "name": "Zola", "description": "Static site generator CLI for creating, building, serving, and checking Markdown-driven websites.", "long_description": "Zola is a static site generator CLI for blogs, docs, and other content-heavy websites built from Markdown, templates, and local assets. Its command surface stays small: initialize a project, build output, run a live-reload dev server, and check content before deployment.\n\n## What It Enables\n- Scaffold a new site with the expected config, content, templates, static, and theme directories.\n- Build deployable static output with overrides for base URL, output path, drafts, and minification.\n- Run a local file-watching preview server and check rendered content plus external links before shipping.\n\n## Agent Fit\n- The command surface is small and most day-to-day workflows map cleanly to repeatable shell commands for build, preview, and validation.\n- `build`, `serve`, `check`, and `completion` are non-interactive once a project exists, which fits CI and inspect-change-verify loops well.\n- CLI output is human-oriented and there is no structured output flag, so agents need to verify results through exit codes, generated files, and served pages rather than JSON parsing.\n\n## Caveats\n- `init` asks configuration questions instead of offering a fully non-interactive project bootstrap path.\n- `serve` is a long-running watcher and local web server, so unattended use needs process supervision and port management.", "category": "dev-tools", "install": "brew install zola", "github": "https:\/\/github.com\/getzola\/zola", "website": "https:\/\/www.getzola.org\/", "source_url": null, "stars": 16705, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "kops", "name": "kops", "description": "Kubernetes cluster lifecycle CLI for provisioning, upgrading, and operating self-managed clusters and instance groups across several clouds.", "long_description": "kops is the Kubernetes project CLI for provisioning and operating self-managed Kubernetes clusters from declarative specs or flags. It manages cluster state, cloud resource changes, and day-2 operations such as upgrades, rolling updates, validation, and kubeconfig export.\n\n## What It Enables\n- Create cluster specs and instance groups, then preview or apply the cloud changes needed to bring them up.\n- Upgrade, validate, rolling-update, and delete clusters, or export kubeconfig and manage secrets, SSH public keys, and keypairs in the kOps state store.\n- Generate Terraform output instead of applying changes directly when you want infrastructure plans in version control or separate approval steps.\n\n## Agent Fit\n- Preview-first flows like `create --dry-run`, `update cluster` without `--yes`, and `rolling-update` without `--yes` fit inspect-change-verify loops for infrastructure work.\n- JSON and YAML output exist on `get`, `validate cluster`, dry-run create, and some toolbox paths, but the structured surface is not uniform across the whole CLI.\n- Useful for agents that already have cloud credentials and state-store access; long-running mutations, provider prerequisites, and optional interactive rolling updates make unattended use heavier.\n\n## Caveats\n- You usually need cloud credentials, DNS and state-store setup, and companion tools like `kubectl`; Terraform is separate when using `--target=terraform`.\n- Provider support is uneven: AWS and GCE are official, while other documented clouds carry beta or alpha status and feature gaps.", "category": "containers", "install": "brew install kops", "github": "https:\/\/github.com\/kubernetes\/kops", "website": "https:\/\/kops.sigs.k8s.io", "source_url": "https:\/\/kops.sigs.k8s.io", "stars": 16566, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Kubernetes" }, { "slug": "nix", "name": "Nix", "description": "Package manager CLI for reproducible builds, dev shells, flake workflows, and Nix store inspection.", "long_description": "Nix is a package manager and build CLI for describing software, development environments, and system configurations as reproducible inputs and store outputs. It covers building and running packages, entering pinned dev shells, querying the Nix store, and working with flake-based dependency graphs.\n\n## What It Enables\n- Build, run, and install packages or apps from local expressions, flakes, or remote refs without relying on host-global dependencies.\n- Create reproducible dev shells and export build environments for local work, CI jobs, and project bootstrap flows.\n- Inspect store paths, dependency closures, flake metadata, and package search results before promoting or debugging changes.\n\n## Agent Fit\n- Many high-value inspection commands expose `--json`, including `nix eval`, `nix path-info`, `nix flake metadata`, `nix flake show`, and `nix print-dev-env`.\n- Commands compose well around explicit store paths, symlinked build results, and exit codes, which makes inspect-change-verify loops practical.\n- Automation fit is mixed at the edges: some important workflows open interactive shells, and newer `nix` and flake surfaces are still marked experimental in the bundled docs.\n\n## Caveats\n- Installing and enabling Nix changes local system state and the recommended installer flow differs by platform and daemon mode.\n- Many real workflows assume existing Nix expressions or flakes, so the CLI is most effective once a repo or environment already models its dependencies in Nix.", "category": "package-managers", "install": "curl -L https:\/\/nixos.org\/nix\/install | sh", "github": "https:\/\/github.com\/NixOS\/nix", "website": "https:\/\/nix.dev\/manual\/nix\/stable\/", "source_url": "https:\/\/nixos.org\/", "stars": 16288, "language": "C++", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Nix" }, { "slug": "nomad", "name": "Nomad", "description": "HashiCorp workload orchestration CLI for planning and running jobs, inspecting allocations and nodes, and operating Nomad clusters.", "long_description": "Nomad is HashiCorp's CLI for operating Nomad clusters and the workloads they schedule. It covers job submission, dry runs, node and allocation inspection, service discovery, variables, and cluster-level operator tasks from one command surface.\n\n## What It Enables\n- Plan, submit, inspect, scale, dispatch, and stop jobs, with dry-run diffs before rollout and guarded updates via check-index.\n- Inspect nodes, allocations, and registered services, read allocation files, and exec into running tasks for debugging and verification.\n- Operate cluster state through ACL, variable, quota, volume, autopilot, and snapshot commands without dropping to raw API calls.\n\n## Agent Fit\n- Many inspect commands expose `-json` or other structured output and share stable non-interactive flags, so they compose well in shell loops once cluster address and auth are configured.\n- `job plan` plus `job run -check-index` gives agents a safer inspect, change, and verify path than blind job updates.\n- Fit weakens around interactive monitor and exec flows, and much of the CLI only becomes useful with a reachable Nomad cluster plus the right ACL context.\n\n## Caveats\n- Useful automation depends on a running Nomad cluster or agent and often ACL tokens, namespaces, and other environment-specific context.\n- JSON support is broad but not universal, and some commands still default to human-oriented text or interactive monitoring behavior.", "category": "cloud", "install": "brew tap hashicorp\/tap && brew install hashicorp\/tap\/nomad", "github": "https:\/\/github.com\/hashicorp\/nomad", "website": "https:\/\/developer.hashicorp.com\/nomad\/commands", "source_url": "https:\/\/www.nomadproject.io\/", "stars": 16261, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "HashiCorp" }, { "slug": "gws", "name": "gws", "description": "Google Workspace CLI for Drive, Gmail, Calendar, Docs, Sheets, Chat, Admin reports, and other Workspace API operations.", "long_description": "gws is a dynamic Google Workspace CLI that builds commands from Google's Discovery documents and adds helper commands for common Workspace jobs. It covers common services like Drive, Gmail, Calendar, Docs, Sheets, Chat, and Admin reports while still allowing raw API access when you need a less common method.\n\n## What It Enables\n- List, create, update, and delete resources across Drive, Gmail, Calendar, Docs, Sheets, Chat, Tasks, Meet, Forms, Classroom, Keep, and Admin reports from one shell surface.\n- Inspect request and response schemas with `gws schema`, then build valid `--params` and `--json` payloads without manually translating REST docs.\n- Use higher-level helpers for common jobs like sending Gmail, appending Sheets rows, uploading Drive files, creating calendar events, or chaining cross-service workflows.\n\n## Agent Fit\n- JSON is the default output, errors are printed as JSON, and `--page-all` can stream paginated results in NDJSON, so follow-up parsing is straightforward.\n- The generated command tree plus `gws schema` gives agents a practical try, inspect, adjust loop even when an API surface changes or a method is unfamiliar.\n- A large bundled `SKILL.md` tree makes it easier to turn raw Workspace calls into repeatable project-specific workflows.\n\n## Caveats\n- Initial setup can require a Google Cloud project, OAuth client configuration, API enablement, and browser-based consent before unattended runs are realistic.\n- README marks the project as under active development, warns about breaking changes before v1.0, and says it is not an officially supported Google product.", "category": "google-workspace", "install": "npm install -g @googleworkspace\/cli", "github": "https:\/\/github.com\/googleworkspace\/cli", "website": null, "source_url": "https:\/\/github.com\/googleworkspace\/cli", "stars": 16063, "language": "Rust", "has_mcp": false, "has_skill": true, "has_json": true, "brand_icon": "google", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "imagemagick", "name": "ImageMagick", "description": "Image processing CLI for converting, inspecting, and transforming images in batch workflows.", "long_description": "ImageMagick is a command-line image processing suite centered on the `magick` command plus helpers such as `identify`, `mogrify`, `compare`, and `montage`. It is built for repeatable file-based image work: conversion, resizing, compositing, metadata inspection, and scripted transforms across large batches.\n\n## What It Enables\n- Convert between many image formats and apply scripted transforms such as resize, crop, rotate, blur, sharpen, annotate, and composite operations.\n- Inspect image dimensions, color data, integrity, and other attributes with `identify`, or write structured JSON metadata for downstream parsing.\n- Batch-process folders or scripted pipelines to generate thumbnails, derivatives, contact sheets, comparisons, and other repeatable image assets.\n\n## Agent Fit\n- It works well in shell loops because commands are usually non-interactive, file-oriented, and documented with stable flags and exit behavior.\n- Machine-readable support is real but uneven: JSON output exists as a format, while many common flows still default to dense text or file outputs that a skill should normalize.\n- Best used as a local media primitive inside broader workflows where a skill encodes format choices, quality settings, naming rules, and safety checks.\n\n## Caveats\n- The option surface is large, and available format features can vary with installed delegate libraries and the active security policy.\n- Some subcommands such as `display`, `import`, and `animate` depend on an X server or GUI context, so not every tool in the suite is equally suitable for headless automation.", "category": "media", "install": "brew install imagemagick", "github": "https:\/\/github.com\/ImageMagick\/ImageMagick", "website": "https:\/\/imagemagick.org\/", "source_url": null, "stars": 15864, "language": "C", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "ImageMagick Studio LLC" }, { "slug": "skaffold", "name": "Skaffold", "description": "Kubernetes workflow CLI for continuous dev loops, image builds, manifest rendering, deploys, and verification.", "long_description": "Skaffold is Google's CLI for building, testing, rendering, deploying, and verifying Kubernetes applications from a `skaffold.yaml` workflow. It is aimed at inner-loop development and CI or CD orchestration rather than raw cluster administration.\n\n## What It Enables\n- Bootstrap a `skaffold.yaml`, then run continuous dev loops that watch source changes, rebuild or sync files, redeploy, tail logs, and clean up on exit.\n- Run build, test, render, apply, deploy, delete, debug, and verify stages separately so teams can compose CI pipelines or GitOps-style render and apply flows.\n- Adapt images and manifests for Kubernetes debugging, port forwarding, and post-deployment verification without hand-wiring each step.\n\n## Agent Fit\n- Useful when an agent needs one command surface for build, test, render, deploy, and verify over an existing Kubernetes app configuration.\n- Structured output exists for config inspection and some helper commands such as `inspect`, `lint`, `schema list`, and build artifact files, which helps skills read config state or hand artifacts between steps.\n- Automation fit is mixed for the main workflows: `dev`, `run`, `debug`, and `verify` mostly stream human-oriented logs, and success depends on Docker credentials, Kubernetes context, and a valid `skaffold.yaml`.\n\n## Caveats\n- It requires a working container and Kubernetes toolchain plus project configuration; Skaffold orchestrates other tools rather than replacing them.\n- Some flows are intentionally long-running or interactive, especially continuous dev and debugging sessions.", "category": "containers", "install": "brew install skaffold", "github": "https:\/\/github.com\/GoogleContainerTools\/skaffold", "website": "https:\/\/skaffold.dev\/", "source_url": null, "stars": 15767, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "kubernetes", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Google" }, { "slug": "packer", "name": "Packer", "description": "Official HashiCorp CLI for validating templates, installing plugins, and building machine images across cloud and virtualization platforms.", "long_description": "Packer is HashiCorp's CLI for turning HCL templates into repeatable machine images and other build artifacts across cloud and virtualization platforms. It also handles template inspection, validation, formatting, and plugin installation around that build workflow.\n\n## What It Enables\n- Define one image pipeline in HCL, then build AMIs, VM images, and other platform-specific artifacts from the same template.\n- Inspect, validate, and format Packer templates before a build so bad variables, missing plugins, and config errors fail earlier.\n- Install and pin required plugins so image-build workflows can be reproduced across CI runners and operator machines.\n\n## Agent Fit\n- Commands such as `init`, `validate`, `inspect`, and `build` are non-interactive by default, exit-code driven, and fit inspect\/change\/verify loops in CI.\n- `-machine-readable` gives parseable stdout, but it is timestamped comma-delimited text rather than JSON, so follow-up parsing is more brittle than JSON-native CLIs.\n- Best fit when an agent is managing an existing image pipeline with known credentials, plugin requirements, and template inputs.\n\n## Caveats\n- Real builds depend on cloud or hypervisor credentials, can take a long time, and may create billable infrastructure.\n- Some modes are human-oriented, such as `-debug` pauses and `-on-error=ask`, so unattended runs should pin non-interactive behavior explicitly.", "category": "cloud", "install": "brew tap hashicorp\/tap && brew install hashicorp\/tap\/packer", "github": "https:\/\/github.com\/hashicorp\/packer", "website": "https:\/\/developer.hashicorp.com\/packer\/docs", "source_url": "https:\/\/developer.hashicorp.com\/packer", "stars": 15621, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "HashiCorp" }, { "slug": "pre-commit", "name": "pre-commit", "description": "Git hook manager for installing, updating, and running version-pinned multi-language hooks across repositories.", "long_description": "pre-commit is a Git hook manager that installs and runs version-pinned hooks from many languages through one `.pre-commit-config.yaml`. It fetches hook repos, provisions isolated runtimes, and executes checks or auto-fixes before commits or in CI.\n\n## What It Enables\n- Install Git hook shims and run configured linters, formatters, and policy checks on staged files, all files, or a ref diff.\n- Generate, validate, migrate, and autoupdate hook configuration so repositories keep using current hook revisions without hand-editing every repo.\n- Try hook repositories locally, cache per-hook environments, and reuse the same checks in local commits, pre-push hooks, and CI jobs.\n\n## Agent Fit\n- Stable subcommands and exit codes make it straightforward to gate commits or CI jobs with `run`, `validate-config`, `validate-manifest`, and `autoupdate`.\n- It composes well in shell workflows because you can target explicit files, hook ids, stages, or ref ranges while reusing cached hook environments between runs.\n- Machine-readable output is limited: commands emit plain text and YAML rather than JSON, and most value depends on being inside a Git repo with a maintained `.pre-commit-config.yaml`.\n\n## Caveats\n- It is only useful once a repository is configured with hook repos and a `.pre-commit-config.yaml`; it is not a general-purpose linter runner by itself.\n- First runs can be slow because hook environments are installed on demand, and some hooks intentionally rewrite files as part of enforcement.", "category": "dev-tools", "install": "pip install pre-commit", "github": "https:\/\/github.com\/pre-commit\/pre-commit", "website": "https:\/\/pre-commit.com\/", "source_url": null, "stars": 15112, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "kind", "name": "kind", "description": "Official CLI for creating local Kubernetes clusters, loading images, and exporting kubeconfig or logs for dev and CI.", "long_description": "kind is the Kubernetes project's CLI for running disposable local clusters as containerized nodes on one machine. It is mainly used to stand up repeatable Kubernetes environments for development, testing, and CI.\n\n## What It Enables\n- Create single-node or multi-node local clusters, choose node images, and tear them down cleanly after tests or debugging.\n- Feed cluster config from YAML or stdin, export kubeconfig, and list clusters or nodes for follow-up automation.\n- Load local Docker images into nodes, build custom node images, and export cluster logs when reproducing CI or local failures.\n\n## Agent Fit\n- Useful as a local environment control layer because commands are explicit, non-TUI, and easy to chain with `kubectl`, image builds, and test runners.\n- Output is mostly plain text or kubeconfig YAML rather than structured JSON, so agents need command-specific parsing and follow-up verification.\n- Best when an agent needs to provision or reset disposable Kubernetes clusters on a machine it already controls, not when it needs full cluster inspection by itself.\n\n## Caveats\n- Requires a supported container runtime such as Docker, Podman, or nerdctl, and many workflows also depend on `kubectl`.\n- Most value is cluster lifecycle and setup; once the cluster exists, day-to-day resource inspection and mutation usually happen through `kubectl` or other Kubernetes CLIs.", "category": "containers", "install": "brew install kind", "github": "https:\/\/github.com\/kubernetes-sigs\/kind", "website": "https:\/\/kind.sigs.k8s.io\/", "source_url": "https:\/\/kind.sigs.k8s.io\/", "stars": 15066, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Kubernetes" }, { "slug": "task", "name": "Task", "description": "Task runner CLI for defining and running project automation, build steps, and developer workflows from `Taskfile.yml` files.", "long_description": "Task is a Make-style task runner that defines project automation in `Taskfile.yml` files and executes named tasks with dependencies, variables, and status checks. It is most useful as a stable entry point for build, test, lint, deploy, and local ops workflows that would otherwise live in ad hoc shell scripts.\n\n## What It Enables\n- Run repo or global workflows such as build, test, lint, deploy, code generation, and local environment setup from named tasks instead of memorizing shell commands.\n- Discover available tasks, summaries, and up-to-date status, then execute only the workflow you need or watch it for file changes.\n- Share and compose automation through included Taskfiles, task dependencies, variables, and parallel execution for multi-step project workflows.\n\n## Agent Fit\n- Works well when a repo already has a maintained Taskfile: agents can list tasks, inspect summaries, check status, and invoke the right workflow from the shell.\n- Machine-readable output exists for task discovery via `--list --json` and includes descriptions and locations, but task execution output is whatever the underlying commands print.\n- Reliability depends on Taskfile quality; prompts, interactive commands, and opaque shell snippets can make unattended runs harder to reason about.\n\n## Caveats\n- Task is an orchestrator, not a service-specific API client, so its practical value comes from the Taskfiles available in the current project or home directory.\n- Some features are explicitly interactive or TTY-sensitive, including warning prompts and `--interactive` variable prompting.", "category": "dev-tools", "install": "brew install go-task\/tap\/go-task", "github": "https:\/\/github.com\/go-task\/task", "website": "https:\/\/taskfile.dev\/", "source_url": null, "stars": 15046, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "yq", "name": "yq", "description": "Command-line processor for querying, transforming, and updating YAML, JSON, XML, CSV, TOML, HCL, INI, and properties files.", "long_description": "yq is a jq-like data processor for reading, reshaping, converting, and updating structured documents from files or stdin. It is most useful as a shell primitive for config files, manifests, API payloads, and multi-step pipelines that need more than plain text parsing.\n\n## What It Enables\n- Read or update nested fields in YAML, JSON, XML, TOML, HCL, INI, properties, CSV, and TSV data without writing custom parsers.\n- Merge multiple config files, create new documents from scratch, and rewrite files in place for automation or repo maintenance tasks.\n- Convert between structured formats and emit JSON or line-delimited JSON for downstream tools, scripts, or agent follow-up steps.\n\n## Agent Fit\n- Flags, stdin support, exit behavior, and non-interactive `eval` or `eval-all` commands make it easy to slot into shell loops and CI jobs.\n- Machine-readable output is solid: explicit input and output format flags, JSON output, and compact single-line JSON reduce parsing friction for agents.\n- Best used as a data-shaping primitive around other CLIs and files, where an agent needs to inspect config state, apply deterministic edits, and verify the result.\n\n## Caveats\n- It does not implement all of `jq`, so some filters or edge-case expectations will not transfer directly.\n- Round-tripping comments and whitespace is best-effort rather than exact, especially in more complex YAML or XML cases.", "category": "data-processing", "install": "brew install yq", "github": "https:\/\/github.com\/mikefarah\/yq", "website": "https:\/\/mikefarah.gitbook.io\/yq\/", "source_url": null, "stars": 14998, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "vercel", "name": "Vercel CLI", "description": "Official Vercel CLI for deployments, project configuration, domains, logs, and API operations.", "long_description": "Vercel CLI is Vercel's official command line for deploying and operating projects on the Vercel platform. It covers local build and preview workflows, remote project management, and direct access to the Vercel API.\n\n## What It Enables\n- Deploy preview or production builds, run local `vercel build` output, and promote, redeploy, or roll back deployments from the shell.\n- Link repos to projects, pull project config and environment variables, and manage projects, teams, domains, DNS, aliases, Blob stores, integrations, and webhooks.\n- Inspect deployments, stream request logs, query usage or activity data, and fall back to `vercel api` for authenticated REST operations the dedicated commands do not cover.\n\n## Agent Fit\n- Many high-value commands expose structured output, including deploy, inspect, logs, env listing, project listing, activity, usage, and direct API responses.\n- It fits inspect, change, and verify loops well because deploy URLs are pipeable, `vercel build` plus `vercel deploy --prebuilt` supports deterministic CI, and non-interactive mode is auto-detected for agents and CI.\n- Automation is strongest when team scope, project linkage, `--yes`, and `VERCEL_TOKEN` are supplied up front; browser login, linking, and `vercel mcp` setup still introduce interactive steps.\n\n## Caveats\n- Most project-scoped commands depend on `.vercel\/project.json` or `.vercel\/repo.json`, and monorepos often need `vercel link --repo` first.\n- Initial authentication uses a browser-based device flow by default, and some setup or destructive flows still prompt unless you provide explicit flags.", "category": "cloud", "install": "npm install -g vercel", "github": "https:\/\/github.com\/vercel\/vercel", "website": "https:\/\/vercel.com\/docs\/cli", "source_url": "https:\/\/vercel.com\/docs\/cli", "stars": 14976, "language": "TypeScript", "has_mcp": true, "has_skill": true, "has_json": true, "brand_icon": "vercel", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Vercel" }, { "slug": "duf", "name": "duf", "description": "Disk usage CLI for listing mounted filesystems, free space, inode usage, and mount metadata.", "long_description": "duf is a disk usage inspection CLI that reports mounted filesystem capacity, free space, usage percentages, and optional inode stats. It is essentially a more scriptable and readable `df` replacement for checking storage state on the current machine.\n\n## What It Enables\n- Inspect local, network, fuse, special, loop, or bind mounts and see size, free space, usage, filesystem type, and mount point.\n- Filter to specific filesystems or mount points, then sort or trim columns to focus on the disks relevant to an incident, preflight check, or host audit.\n- Export mount inventory and capacity data as JSON for follow-up parsing, alerts, or automated environment diagnostics.\n\n## Agent Fit\n- `--json`, predictable flags, and straightforward stderr or exit-code behavior make it easy to wrap in scripts when an agent needs storage state from the current host.\n- The scope is inspect-only and host-local, so it helps answer \"what is full?\" but does not manage partitions, volumes, or cloud disks.\n- Best used inside larger shell workflows for system checks, low-space debugging, and validation before running disk-heavy tasks.\n\n## Caveats\n- Default output is a human-oriented colored table, so automation should prefer `--json` or explicit `--output` selections.\n- It only reports mounts visible on the machine where it runs; remediation or remote storage actions still need other CLIs.", "category": "system-monitoring", "install": "brew install duf", "github": "https:\/\/github.com\/muesli\/duf", "website": null, "source_url": null, "stars": 14856, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "beets", "name": "beets", "description": "Music library manager for importing, autotagging, querying, and reorganizing local audio collections.", "long_description": "beets is a local music library manager that imports audio files into a catalog, matches releases against MusicBrainz and other sources, and rewrites tags and filenames to a chosen library layout. Its plugin system extends that core into export, playlist, artwork, transcoding, and player-sync workflows.\n\n## What It Enables\n- Import folders of music, match albums or tracks against MusicBrainz, and copy, move, rename, or retag files into a consistent library structure.\n- Query the library, batch-modify metadata, update file tags, and reorganize files from the shell once the collection is in beets' database.\n- Add plugins for jobs like duplicate detection, cover art and lyrics fetching, transcoding, playlist generation, and exporting library data as JSON or JSON Lines.\n\n## Agent Fit\n- The core commands work well in local inspect and change loops because the library is queryable from the shell and batch edits can be applied deterministically once configuration is in place.\n- Machine-readable output is real but uneven: the `export` plugin provides JSON and JSON Lines, while many default commands print human-oriented text or template-formatted output.\n- Best suited to project-specific skills around personal media cleanup or ingestion pipelines, not unattended end-to-end tagging, because the highest-value import flow is interactive by default and plugin dependencies vary.\n\n## Caveats\n- Import, modify, move, and write operations can rename, relocate, and retag files, so safe automation depends on a configured library path and good backups.\n- Many useful plugins rely on extra Python packages or external binaries such as ffmpeg, ImageMagick, GStreamer, or Acoustid tooling.", "category": "media", "install": "pipx install beets", "github": "https:\/\/github.com\/beetbox\/beets", "website": "https:\/\/beets.io\/", "source_url": null, "stars": 14818, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "direnv", "name": "direnv", "description": "Per-directory environment manager for loading approved `.envrc` or `.env` files into shells and commands.", "long_description": "direnv manages per-directory environment state by evaluating approved `.envrc` or `.env` files and exporting the resulting diff to your shell or a child process. It is mainly used to keep project-specific variables, PATH changes, secrets, and toolchain setup tied to a repo instead of a global shell profile.\n\n## What It Enables\n- Load project-specific environment variables, PATH changes, and secrets automatically when you enter a repo after approving its `.envrc` or `.env` file.\n- Run build, test, deploy, or utility commands inside a directory's configured environment with `direnv exec`, without manually sourcing activation scripts.\n- Export environment diffs for shell hooks, JSON consumers, or GitHub Actions environment files so the same env definition can drive local and CI workflows.\n\n## Agent Fit\n- `direnv exec` gives agents a direct non-interactive way to run other CLIs inside the environment a project expects.\n- `direnv export json` and `status --json` provide structured state, but most day-to-day use still revolves around shell hooks rather than a broad standalone command surface.\n- Best used as infrastructure around repo workflows and other CLIs, not as the main action primitive itself.\n\n## Caveats\n- New or changed `.envrc` or `.env` files must be explicitly approved with `direnv allow`, which blocks unattended use until trust is established.\n- `.envrc` files are shell code executed in a bash subprocess, so behavior and safety depend on trusted repo content and shell-compatible setup.", "category": "dev-tools", "install": "curl -sfL https:\/\/direnv.net\/install.sh | bash", "github": "https:\/\/github.com\/direnv\/direnv", "website": "https:\/\/direnv.net\/", "source_url": null, "stars": 14757, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "cargo", "name": "Cargo", "description": "Official Rust package manager and build CLI for creating crates, managing dependencies, and building, testing, and publishing Rust packages.", "long_description": "Cargo is Rust's official package manager and build tool for working with local crates and workspaces. It covers project scaffolding, dependency and manifest edits, builds, tests, installs, publishing, and registry or workspace inspection from one command surface.\n\n## What It Enables\n- Create new crates and workspaces, add or remove dependencies, and inspect manifests or resolved dependency graphs.\n- Build, check, run, test, document, and benchmark Rust packages with workspace, target, profile, and feature controls.\n- Install binaries from crates.io, git, or local paths, and publish or manage packages on registries like crates.io.\n\n## Agent Fit\n- Good shell fit for Rust projects: most commands are non-interactive, accept explicit paths and flags, and return stable exit codes.\n- `cargo metadata`, `cargo locate-project`, and `--message-format json` on build-style commands give agents structured project and compiler data for follow-up parsing.\n- Output is not uniform across the whole CLI; many package and registry commands are still text-first, so automation often combines JSON-capable commands with targeted text parsing.\n\n## Caveats\n- Installing Cargo usually means installing the full Rust toolchain through `rustup`, not a standalone Cargo package.\n- Behavior depends on the local toolchain, manifest, lockfile, and sometimes registry access, so reproducibility benefits from explicit versions and flags like `--locked` or `--offline` when relevant.", "category": "package-managers", "install": "curl https:\/\/sh.rustup.rs -sSf | sh", "github": "https:\/\/github.com\/rust-lang\/cargo", "website": "https:\/\/doc.rust-lang.org\/cargo", "source_url": "https:\/\/doc.rust-lang.org\/cargo", "stars": 14686, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Rust" }, { "slug": "gron", "name": "gron", "description": "JSON exploration CLI for flattening files, URLs, or stdin into greppable path assignments and rebuilding filtered results.", "long_description": "gron flattens JSON into one assignment per path so you can inspect unfamiliar payloads with line-oriented tools like `grep`, `diff`, and `sed`. It can read files, URLs, or stdin, and it can rebuild filtered assignments back into valid JSON.\n\n## What It Enables\n- Explore unfamiliar API responses or config blobs by surfacing the full path for matching keys and values.\n- Filter, diff, or slice JSON with standard text tools, then reconstruct the kept assignments back into JSON with `--ungron`.\n- Emit each path and value as a JSON stream row with `--json`, or process newline-delimited JSON objects with `--stream`.\n\n## Agent Fit\n- File, URL, and stdin inputs plus explicit exit codes make it easy to drop into shell inspection loops without interactive prompts.\n- `--json` gives agents a structured `[path, value]` stream when the default assignment text would be awkward to parse.\n- Best suited to discovery and quick extraction; the project itself warns that grep and sed style mutation pipelines are error-prone for durable automation.\n\n## Caveats\n- It is not a full query language like `jq`; its main strength is path discovery and coarse filtering, not complex JSON transforms.\n- Default output is plain text assignments, so agents that need structured follow-up parsing should opt into `--json` or ungron the filtered result.", "category": "data-processing", "install": "brew install gron", "github": "https:\/\/github.com\/tomnomnom\/gron", "website": null, "source_url": null, "stars": 14392, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "semgrep", "name": "Semgrep", "description": "Static analysis CLI for scanning code with Semgrep rules, custom patterns, CI checks, and optional autofixes.", "long_description": "Semgrep is a static analysis CLI for searching code with structural patterns and reusable rules, then running those checks locally or in CI. It covers code-quality, security, policy, supply-chain, and secrets workflows from the shell.\n\n## What It Enables\n- Scan repositories with registry rules, local rule packs, or one-off patterns to find insecure APIs, policy violations, and refactor targets across many languages.\n- Validate and iterate on custom Semgrep rules, then run them in CI or pull-request scans to gate changes and report only new findings.\n- Emit JSON, SARIF, JUnit, or GitLab outputs and optionally apply supported autofixes, making it usable in pipelines and follow-up remediation loops.\n\n## Agent Fit\n- `semgrep scan` and `semgrep ci` are non-interactive and shell-friendly, with `--json` and `--sarif`, stable exit behavior, and file outputs that fit parse-and-act workflows.\n- It works well for agents that need to inspect a codebase, test hypotheses with inline patterns, or verify remediations after edits without leaving the terminal.\n- Coverage is uneven across editions: advanced cross-file security analysis, some secrets and supply-chain workflows, cloud findings, and parts of MCP depend on Semgrep login, tokens, or Pro and AppSec features.\n\n## Caveats\n- The open-source engine is explicitly limited for some security use cases and can miss true positives that require cross-function or cross-file analysis.\n- MCP support is real but still beta and hosted or cloud-backed flows add authentication and deployment assumptions beyond a simple local scan.", "category": "security", "install": "brew install semgrep", "github": "https:\/\/github.com\/semgrep\/semgrep", "website": "https:\/\/semgrep.dev", "source_url": "https:\/\/semgrep.dev", "stars": 14363, "language": "OCaml", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Semgrep" }, { "slug": "git-lfs", "name": "Git LFS", "description": "Git extension for tracking large files, migrating history to LFS pointers, and locking binary assets in repositories.", "long_description": "Git LFS extends Git with pointer-based storage for large files so repositories can track binaries without storing the full blobs in normal Git history. It also covers migration, fetch and pull workflows, and optional file locking for teams working with large assets.\n\n## What It Enables\n- Track file patterns in `.gitattributes` so large binaries are stored as LFS pointers while normal Git commits stay smaller.\n- Inspect LFS-tracked files, fetch or pull object content, and see what large objects are staged, downloaded, or still missing.\n- Migrate existing repository history into or out of LFS, and lock shared binary files to coordinate edits on supported remotes.\n\n## Agent Fit\n- Several high-value commands expose stable `--json` output, including `status`, `ls-files`, `track`, `fetch`, `lock`, `locks`, and `unlock`.\n- Most day-to-day commands are non-interactive and scriptable, but behavior is tightly coupled to the current repo, Git hooks, and remote LFS server support.\n- Best used inside inspect\/change\/verify loops for repositories that already use large binaries, not as a general-purpose file transfer CLI.\n\n## Caveats\n- `git lfs migrate` rewrites history by default, so automation needs explicit validation and coordinated force-pushes.\n- Value is narrow outside repos that actually use Git LFS, and some workflows depend on credentials plus a compatible hosting service.", "category": "github", "install": "brew install git-lfs", "github": "https:\/\/github.com\/git-lfs\/git-lfs", "website": "https:\/\/git-lfs.com\/", "source_url": "https:\/\/git-lfs.com\/", "stars": 14120, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "tokei", "name": "tokei", "description": "Code statistics CLI for counting files, lines, code, comments, and blanks across source trees.", "long_description": "tokei is a source tree metrics CLI for quickly summarizing language mix and line counts. It scans directories or files and reports files, total lines, code, comments, and blanks, with optional per-file and machine-readable output.\n\n## What It Enables\n- Measure language mix, file counts, and code, comment, and blank-line totals for a repo, subtree, or set of paths.\n- Drill down to per-file statistics, sort results by files, lines, blanks, code, or comments, and exclude paths when scoping an audit.\n- Export totals as JSON or stream per-file JSON records for CI baselines, repository reports, or follow-up scripts.\n\n## Agent Fit\n- `--output json` and `--streaming json` give agents structured totals or per-file records without scraping the default table view.\n- Commands are non-interactive, respect ignore files by default, and combine cleanly with path, exclude, type, and sort flags in inspect-parse-report loops.\n- This is inspection-only and metric-focused: it helps agents find where code volume sits, not whether code is correct, complex, or safe.\n\n## Caveats\n- YAML and CBOR output require extra compile-time features; JSON is the portable structured format available in standard builds.\n- Counts depend on language detection and ignore rules, so ambiguous extensions or excluded paths can change totals until you adjust patterns or flags.", "category": "dev-tools", "install": "brew install tokei", "github": "https:\/\/github.com\/XAMPPRocky\/tokei", "website": "https:\/\/tokei.rs", "source_url": null, "stars": 14039, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "cloudflared", "name": "cloudflared", "description": "Official Cloudflare CLI for creating and running tunnels, routing hostnames or private networks, and accessing protected services.", "long_description": "cloudflared is Cloudflare's tunnel and access client for connecting private services to Cloudflare without opening inbound ports. It can publish local HTTP services, route private TCP or IP traffic through Cloudflare, and authenticate clients into Access-protected apps.\n\n## What It Enables\n- Create named tunnels, run tunnel connectors, and map public hostnames, load balancers, or private network routes to local services.\n- Expose localhost or internal apps for development or production, including quick temporary tunnels and durable DNS-backed routes.\n- Authenticate into Access-protected apps, proxy SSH or other TCP traffic through Cloudflare, and stream logs or run diagnostics against connectors.\n\n## Agent Fit\n- The CLI maps well to inspect, change, and verify loops: you can create, list, inspect, delete, route, and health-check tunnels directly from the shell.\n- Structured output is present but uneven: tunnel listings and route queries support `--output json|yaml`, `tail` supports `--output json`, and token commands emit JSON, while many setup and run flows are plain text or logs.\n- Works best when account, zone, and tunnel conventions are already captured in skills; browser login, origin certs, and long-running service management make unattended use more involved than a pure CRUD API CLI.\n\n## Caveats\n- Production use requires Cloudflare account setup and credentials; `tunnel login` and `access login` can open browser-based flows, while named tunnels depend on certs or tokens.\n- Quick tunnels are for testing only, and the core `tunnel run` workflow is a daemon-style process rather than a short request-response command.", "category": "networking", "install": "brew install cloudflared", "github": "https:\/\/github.com\/cloudflare\/cloudflared", "website": "https:\/\/developers.cloudflare.com\/tunnel\/", "source_url": null, "stars": 13406, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "cloudflare", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Cloudflare" }, { "slug": "sshuttle", "name": "sshuttle", "description": "SSH-based transparent proxy CLI for routing selected subnets and DNS through a remote host without a full VPN setup.", "long_description": "sshuttle creates an SSH-backed transparent proxy that makes selected remote subnets reachable from your machine or router. It sits between one-off SSH port forwards and a full VPN by capturing traffic locally and relaying it through a remote host that only needs Python.\n\n## What It Enables\n- Reach private services on remote subnets over SSH without setting up per-port forwards or deploying a separate VPN server.\n- Route all traffic or specific IPv4 and IPv6 ranges, plus DNS when supported, through a remote host and optionally auto-discover remote routes or hostnames.\n- Bring up repeatable access to internal environments from flags, config files, environment variables, or daemonized service runs.\n\n## Agent Fit\n- Useful when an agent first needs network reachability to private hosts, dashboards, APIs, or databases behind an SSH-accessible bastion.\n- The CLI is scriptable through flags, config files, and `SSHUTTLE_ARGS`, but it exposes only plain log output and exit codes, not structured status data.\n- Best inside supervised workflows or skills: it changes local firewall state, often needs sudo, and long-lived tunnels are more brittle than short inspect-or-mutate commands.\n\n## Caveats\n- Local root or sudo is required, and the remote host still needs a usable Python 3.9+ installation.\n- Support depends on the selected method and platform; for example, TPROXY is the only documented method with UDP support, and `--sudoers-no-modify` is explicitly marked insecure.", "category": "networking", "install": "brew install sshuttle", "github": "https:\/\/github.com\/sshuttle\/sshuttle", "website": "https:\/\/sshuttle.readthedocs.io\/en\/stable\/", "source_url": null, "stars": 13164, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "ast-grep", "name": "ast-grep", "description": "Structural code search, lint, and rewrite CLI built on AST patterns.", "long_description": "ast-grep is a structural code search and rewriting CLI built on tree-sitter ASTs. It lets you match code by syntax shape, then run one-off rewrites or reusable lint rules across supported languages.\n\n## What It Enables\n- Search a repo for syntax patterns and captured nodes instead of raw text matches, including matches read from stdin or filtered by file globs.\n- Rewrite matched code with replacement templates, either as targeted one-off codemods or bulk updates across many files.\n- Define YAML rules, scaffold and test them, then run repo-wide scans that emit diagnostics or SARIF for CI and cleanup workflows.\n\n## Agent Fit\n- `run` and `scan` both support real `--json` output, and `scan` also emits SARIF, so matches and diagnostics are straightforward to parse in follow-up steps.\n- The CLI is built for non-interactive use first: paths, stdin, globs, inline rules, thread control, and inspect output make it easy to chain into search, edit, and verify loops.\n- Best for codemods, lint enforcement, and targeted repository inspection; agents still need correct language selection and precise rules, while interactive review mode is mainly for humans.\n\n## Caveats\n- Coverage depends on supported parsers and correct language detection, so unsupported syntax or the wrong language choice will miss matches.\n- Repeatable team workflows usually depend on checked-in rule files and `sgconfig.yml`; interactive rewrite sessions are less suitable for unattended runs.", "category": "dev-tools", "install": "brew install ast-grep", "github": "https:\/\/github.com\/ast-grep\/ast-grep", "website": "https:\/\/ast-grep.github.io\/", "source_url": null, "stars": 12792, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "cdk", "name": "AWS CDK CLI", "description": "Official AWS CDK CLI for initializing CDK apps, synthesizing templates, diffing changes, bootstrapping environments, and deploying AWS stacks.", "long_description": "AWS CDK CLI is AWS's command line toolkit for running CDK apps through their infrastructure lifecycle. It initializes projects, synthesizes CloudFormation, diffs planned changes, bootstraps environments, deploys or destroys stacks, and supports faster development loops with watch and hotswap.\n\n## What It Enables\n- Initialize CDK apps, list stacks, inspect context, and synthesize CloudFormation templates or full cloud assemblies from code.\n- Bootstrap target accounts, diff planned changes, deploy, rollback, destroy, import, migrate, or drift-check stacks from the shell.\n- Run faster development loops with `watch` and `hotswap`, and hand off stack outputs via JSON files for follow-up automation.\n\n## Agent Fit\n- Commands are explicit and scriptable once `--app`, credentials, and target stacks are known, with flags like `--yes`, `--require-approval`, `--outputs-file`, and `--progress` for CI-style runs.\n- Real structured output exists, but it is uneven: `--json` mainly covers printed templates and inspect commands, while deploy and diff still produce mostly human-oriented progress and reports.\n- Fits best as the action layer on top of a project-specific skill that knows app entrypoints, stack selectors, AWS accounts, and when development-only hotswap behavior is acceptable.\n\n## Caveats\n- Useful operation depends on an existing CDK app or cloud assembly plus configured AWS credentials and bootstrapped target environments.\n- `watch`, `hotswap`, and `hotswap-fallback` intentionally bypass normal CloudFormation deployment behavior and are for development, not production.", "category": "cloud", "install": "npm install -g aws-cdk", "github": "https:\/\/github.com\/aws\/aws-cdk", "website": "https:\/\/docs.aws.amazon.com\/cdk\/v2\/guide\/cli.html", "source_url": "https:\/\/aws.amazon.com\/cdk", "stars": 12688, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "AWS" }, { "slug": "nmap", "name": "nmap", "description": "Network scanner for host discovery, port scanning, service fingerprinting, OS detection, traceroute, and NSE script scans.", "long_description": "nmap is a network reconnaissance and security auditing CLI for discovering hosts and interrogating them with many scan types. Beyond basic port scans, it can fingerprint services and operating systems, trace routes, and run the Nmap Scripting Engine against targets.\n\n## What It Enables\n- Discover live hosts, open ports, and exposed protocols across IPs, ranges, and larger network slices.\n- Fingerprint services, guess operating systems, trace hop paths, and compare network exposure before or after infrastructure changes.\n- Run NSE scripts for discovery, deeper service interrogation, and vulnerability-oriented checks against reachable targets.\n\n## Agent Fit\n- Flag-driven, non-interactive commands work well in shell loops for inventory, verification, and recurring scans.\n- Structured output exists, but it is XML rather than JSON; the man page explicitly positions XML as the preferred format for software integrations.\n- Best for inspect workflows and controlled audits where an agent can parse findings and decide follow-up probes, not for unattended remediation.\n\n## Caveats\n- Many advanced scan types need raw-socket privileges or admin access, and behavior changes when run unprivileged.\n- NSE includes intrusive and dangerous scripts, and the docs warn against scanning networks or running certain checks without permission.", "category": "security", "install": "brew install nmap", "github": "https:\/\/github.com\/nmap\/nmap", "website": "https:\/\/nmap.org\/book\/man.html", "source_url": null, "stars": 12509, "language": "C++", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Nmap Project" }, { "slug": "grpcurl", "name": "grpcurl", "description": "gRPC CLI for listing services, describing schemas, and invoking RPC methods with JSON or protobuf text payloads.", "long_description": "grpcurl is a gRPC inspection and invocation CLI for probing live endpoints or local protobuf descriptors from the shell. It lets you list services, inspect schemas, and call methods without generating a client first.\n\n## What It Enables\n- List exposed gRPC services and methods, or inspect symbols from local `.proto` and protoset files before touching a live server.\n- Invoke unary, server-streaming, client-streaming, and bidi RPCs with JSON request bodies, stdin pipelines, custom metadata headers, TLS, mTLS, and request time limits.\n- Describe messages and services, print request templates, and export discovered descriptors back out as `.proto` files or protosets for debugging and documentation.\n\n## Agent Fit\n- JSON is the default request and response format, so agents can pipe bodies in, parse returned messages, and keep gRPC work inside ordinary shell loops.\n- The same binary covers inspect and action paths: `list` and `describe` help an agent learn the API surface, then direct invocation closes the inspect-change-verify loop.\n- Automation stays strong when reflection is enabled or descriptor files are available ahead of time; fully interactive bidi streaming is possible, but less ergonomic in unattended runs.\n\n## Caveats\n- If a server does not expose reflection, you need the relevant `.proto` sources or protoset files before grpcurl can describe symbols or encode requests correctly.\n- List and describe output is mostly human-oriented text, so schema discovery often needs follow-up parsing or exported descriptors instead of native JSON.", "category": "http-apis", "install": "brew install grpcurl", "github": "https:\/\/github.com\/fullstorydev\/grpcurl", "website": null, "source_url": null, "stars": 12492, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "FullStory" }, { "slug": "broot", "name": "broot", "description": "Terminal file browser for navigating directory trees, searching files, previewing content, and running file actions.", "long_description": "broot is a fullscreen terminal file browser for exploring directory trees, narrowing them with fuzzy or content search, previewing files, and launching actions on selections. It covers local filesystem navigation and file management more than script-first automation.\n\n## What It Enables\n- Traverse large directory trees, filter by name or file content, and return a selected path or `cd` target back to the shell.\n- Preview text and images, inspect git state, and surface sizes, dates, permissions, and filesystem usage without leaving the terminal.\n- Open, edit, move, copy, delete, chmod, or batch-apply custom verbs to selected or staged files.\n\n## Agent Fit\n- `--cmd`, `:pp` or `:pt`, `--verb-output`, and Unix `--send` or `--get-root` hooks make it usable in shell wrappers and paired-tool workflows.\n- There is no JSON mode, and exported paths or trees are plain text, so machine parsing is limited and brittle.\n- Agent fit is mixed: useful when a workflow can drive the TUI or coordinate with a human, weaker as a headless inspect or change or verify primitive.\n\n## Caveats\n- `cd` handoff depends on the installed `br` shell function rather than the `broot` binary alone.\n- Remote control via `--listen` and `--send` is Unix-only.", "category": "file-management", "install": "cargo install --locked broot", "github": "https:\/\/github.com\/Canop\/broot", "website": "https:\/\/dystroy.org\/broot", "source_url": null, "stars": 12474, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "kustomize", "name": "Kustomize", "description": "Kubernetes manifest customization CLI for building overlays, applying patches, and rendering YAML without templates.", "long_description": "Kustomize is the Kubernetes manifest customization CLI built around `kustomization.yaml` files. It composes bases, overlays, patches, generators, and optional functions into rendered YAML without templating.\n\n## What It Enables\n- Render environment-specific Kubernetes manifests from shared bases, overlays, patches, labels, namespaces, images, and generators.\n- Create or edit `kustomization.yaml` files from the shell, including adding resources, setting images or replicas, and fixing older config syntax.\n- Vendor remote configuration into a local directory with `localize`, then hand the rendered YAML to `kubectl`, CI, or review steps.\n\n## Agent Fit\n- `kustomize build` is deterministic and non-interactive, so agents can inspect generated YAML, diff outputs, and pipe results into follow-up commands.\n- The tool works mainly on files rather than live cluster state, which keeps edits auditable but usually means pairing it with `kubectl` for apply and verification.\n- Structured output is limited: core workflows are YAML-first, while JSON is only available on ancillary commands such as `version -o json` and hidden `openapi fetch --format json`.\n\n## Caveats\n- `localize` is marked alpha, and its source notes that Helm and KRM plugin fields are not yet localized.\n- Plugin, Helm, and function-based flows can require extra flags, external binaries, or container execution, which raises the complexity of unattended runs.", "category": "containers", "install": "brew install kustomize", "github": "https:\/\/github.com\/kubernetes-sigs\/kustomize", "website": "https:\/\/kubectl.docs.kubernetes.io\/references\/kustomize\/", "source_url": "https:\/\/kubectl.docs.kubernetes.io\/installation\/kustomize\/", "stars": 11967, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Kubernetes" }, { "slug": "mycli", "name": "mycli", "description": "MySQL client for interactive querying, schema-aware completion, and batch SQL execution.", "long_description": "mycli is a MySQL client that combines an interactive prompt with batch SQL execution, schema-aware completion, and flexible result formatting. It fits best when you want one CLI for both exploratory database work and scripted query runs.\n\n## What It Enables\n- Connect to MySQL servers, list databases or tables, and run ad hoc SQL with completions, saved queries, and editor handoff.\n- Execute SQL from `-e`, stdin, or sourced files, then emit table, CSV, or TSV output or redirect results into files and shell commands.\n- Reuse DSNs, MySQL config files, SSH tunnel settings, SSL settings, and keyring-backed passwords when moving between environments.\n\n## Agent Fit\n- Batch mode, `--execute`, `--noninteractive`, and `--format` flags give agents a real non-interactive path for running SQL.\n- CSV and TSV are first-class output modes, and JSONL is available as a supported table format for workflows that need structured records.\n- Most differentiation is still human-first: autocomplete, syntax highlighting, history search, and prompt editing matter more to operators than to unattended agents.\n\n## Caveats\n- There is no simple dedicated `--json` flag; JSONL output depends on table-format configuration or interactive format changes.\n- Credentials and live database reachability are required, and SSH or SSL setup can add extra session friction.", "category": "databases", "install": "pip install -U 'mycli[all]'", "github": "https:\/\/github.com\/dbcli\/mycli", "website": "https:\/\/www.mycli.net", "source_url": null, "stars": 11882, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "mysql", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "instaloader", "name": "Instaloader", "description": "Instagram downloader CLI for archiving profiles, hashtags, stories, saved posts, and post metadata.", "long_description": "Instaloader is an unofficial Instagram archiving CLI that downloads media plus associated captions, comments, geotags, and metadata for profiles and other Instagram targets. It is built for exporting and updating local copies of Instagram content rather than changing account state.\n\n## What It Enables\n- Archive public or followed private profiles, including posts, profile pictures, stories, highlights, tagged posts, reels, and IGTV media.\n- Download hashtag, location, feed, saved-post, followee, and single-post targets, then refresh archives incrementally with `--fast-update` or `--latest-stamps`.\n- Save captions, comments, geotags, and metadata JSON alongside downloaded media for later parsing, filtering, or re-download workflows.\n\n## Agent Fit\n- Recurring non-interactive runs are workable once a session file or imported browser cookies exist, so it can back scheduled archive jobs and scripted exports.\n- Machine-readable output is file-based rather than `--json` stdout: it writes metadata and resume JSON files that tools like `jq` can process, while terminal output is mostly progress logs.\n- Useful for agents that need to collect Instagram content or inspect downloaded metadata, but the scope is read-only and unattended runs are less predictable when login challenges or platform limits appear.\n\n## Caveats\n- Many useful targets require authentication, and login can involve browser checkpoints, cookie import, or already-saved session files.\n- Instagram rate limits and platform changes can interrupt or break scraping, especially from cloud, VPN, or repeatedly restarted sessions.", "category": "media", "install": "pip install instaloader", "github": "https:\/\/github.com\/instaloader\/instaloader", "website": "https:\/\/instaloader.github.io\/", "source_url": "https:\/\/instaloader.github.io\/", "stars": 11721, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "grype", "name": "grype", "description": "Vulnerability scanner for container images, filesystems, files, and SBOMs, with commands to query its local vulnerability database.", "long_description": "Grype scans container images, directories, files, and SBOM input against a local vulnerability database to find known package vulnerabilities. It is mainly a read-side security primitive for CI, supply-chain checks, and post-build verification.\n\n## What It Enables\n- Scan container images, filesystems, single files, and Syft SBOMs for known vulnerabilities across OS and language packages.\n- Pipe Syft JSON or point at an SBOM directly when you want vulnerability matching without re-cataloging the target.\n- Query the local vulnerability DB for advisory records, affected packages, and provider metadata before deciding what to patch or suppress.\n\n## Agent Fit\n- JSON, SARIF, CycloneDX, and template output make it easy to parse findings, gate builds, or hand results to follow-up tools.\n- The main scan flow is non-interactive and exposes stable exit behavior, including a dedicated threshold failure code when `--fail-on` is triggered.\n- Best for inspect and verify loops; it tells an agent what is vulnerable, but fixing or redeploying still depends on other package, image, or deployment CLIs.\n\n## Caveats\n- Results are only as current as the local vulnerability database, so stale DB state weakens unattended scans.\n- Scanning remote images may require Docker, Podman, or registry access and credentials, depending on the source scheme you use.", "category": "security", "install": "curl -sSfL https:\/\/get.anchore.io\/grype | sudo sh -s -- -b \/usr\/local\/bin", "github": "https:\/\/github.com\/anchore\/grype", "website": "https:\/\/oss.anchore.com\/docs\/guides\/vulnerability\/getting-started\/", "source_url": null, "stars": 11681, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Anchore" }, { "slug": "bandwhich", "name": "bandwhich", "description": "Terminal bandwidth monitor for live network usage by process, connection, and remote host.", "long_description": "bandwhich is a local network monitor for seeing which processes and connections are using bandwidth right now. It sniffs an interface, maps traffic back to local processes, and can show the results in a fullscreen terminal view or a raw text stream.\n\n## What It Enables\n- See which local processes are uploading or downloading the most data on a given interface.\n- Inspect live bandwidth by individual connection or by remote IP or hostname when tracking down unexpected traffic.\n- Capture a lightweight text stream of current network activity for local debugging or ad hoc shell-based monitoring.\n\n## Agent Fit\n- Useful when an agent needs to inspect live local network usage and attribute it to processes, sockets, or remote hosts.\n- The automation surface is weaker than typical agent-friendly CLIs because `--raw` is plaintext refresh output rather than JSON, and the default mode is a fullscreen TUI.\n- Best fit for short diagnostic loops on a machine the agent already controls, especially when combined with other shell tools for filtering or logging.\n\n## Caveats\n- Packet capture needs elevated privileges on Linux, and Windows users may need `npcap` installed before it works.\n- README marks the project as passively maintained, so it is not a fast-moving tool.", "category": "system-monitoring", "install": "brew install bandwhich", "github": "https:\/\/github.com\/imsnif\/bandwhich", "website": null, "source_url": null, "stars": 11596, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "git-cliff", "name": "git-cliff", "description": "Generate changelogs and release notes from Git history using conventional commits or custom parsers.", "long_description": "git-cliff generates changelogs and release notes from Git history using conventional commits or custom parsers and templates. It is built for release workflows where you want reproducible notes, optional remote metadata, and semver bumps from the shell.\n\n## What It Enables\n- Generate changelogs for full history, unreleased work, specific tag ranges, or merged history across multiple repositories.\n- Shape release notes with config and templates, filter commits by path, tag, or range, and write or prepend `CHANGELOG.md` in CI.\n- Export changelog context as JSON, reuse JSON context as input, and enrich releases with contributor or pull request metadata from GitHub, GitLab, Gitea, Bitbucket, or Azure DevOps.\n\n## Agent Fit\n- `--context` gives real JSON output, and the main workflow is flag-driven and non-interactive, so it fits scripted release pipelines well.\n- Best used as a release-notes primitive: an agent can inspect commit ranges, render notes, and calculate the next version, then hand off tagging or publishing to other tools.\n- Fit depends on commit hygiene and config quality; without conventional commits or tuned parsers, generated output can be noisy.\n\n## Caveats\n- It generates changelog content but does not create Git tags or publish releases for you.\n- Remote enrichment needs tokens or API access, and offline runs skip that extra metadata.", "category": "github", "install": "brew install git-cliff", "github": "https:\/\/github.com\/orhun\/git-cliff", "website": "https:\/\/git-cliff.org\/", "source_url": null, "stars": 11537, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "git", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "changesets", "name": "Changesets", "description": "Release workflow CLI for adding changesets, versioning packages, generating changelogs, and publishing npm releases.", "long_description": "Changesets is a release workflow CLI for package repositories that stores release intent in checked-in `.changeset` files, then turns those files into version bumps, changelog updates, and publishes. It is built around monorepos, but it also supports single-package repos and private apps tracked through `package.json`.\n\n## What It Enables\n- Capture release intent per change by creating `.changeset` files with package bump types and human-written summaries.\n- Turn accumulated changesets into coordinated package version bumps, internal dependency updates, changelog entries, and git tags across a repo.\n- Gate CI or release automation with `changeset status`, then publish unpublished packages to npm or trigger other release workflows from the tags it creates.\n\n## Agent Fit\n- Commands like `init`, `version`, `status`, `publish`, and `tag` are deterministic shell steps that fit inspect\/change\/verify loops in CI and release scripts.\n- `changeset status --output` provides a machine-readable release plan, and missing-changeset cases fail with a non-zero exit code that automation can enforce.\n- `add` is prompt-driven by default, and `publish` may require npm auth or OTP input, so unattended agents work best when changeset files and credentials are already in place.\n\n## Caveats\n- Structured output is limited: the JSON release plan is written to a file via `status --output`, while most commands print human-oriented logs to stdout.\n- `publish` assumes the last commit is the release commit and should be run in a disciplined release flow to avoid tagging or publishing the wrong state.", "category": "github", "install": "npm install -D @changesets\/cli", "github": "https:\/\/github.com\/changesets\/changesets", "website": null, "source_url": "https:\/\/github.com\/changesets\/changesets", "stars": 11502, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "dust", "name": "dust", "description": "Disk usage CLI for finding large directories, files, and file types in a size-sorted tree.", "long_description": "dust is a disk-usage inspection CLI that surfaces the biggest directories and files in a size-sorted tree instead of raw `du` totals. It is mainly used for local cleanup, build-cache investigation, and quickly understanding where space is going across one or more paths.\n\n## What It Enables\n- Find the largest directories or files under a path without manually piping `du` through `sort`, and recurse only into the heavy branches.\n- Switch between disk usage, apparent size, file counts, file types, and time-based views to understand what is taking space or changing.\n- Feed paths from stdin or files, filter by regex or minimum size, and emit a JSON tree for follow-up scripting or cleanup reports.\n\n## Agent Fit\n- `-j` outputs a structured tree that is easy to pipe into `jq` or consume in scripted cleanup and CI diagnostics.\n- Flags for file-only views, directory collapse, regex filters, no-progress mode, and screen-reader output make headless local inspection predictable.\n- Best for inspect-and-decide loops on local filesystems; the default output is optimized for humans, and the tool does not reclaim space by itself.\n\n## Caveats\n- It only inspects local paths, so any deletion or cleanup still has to be done with other CLIs.\n- Reported sizes can differ between allocated disk usage and apparent size, so automation may need `-s` or fixed output flags for consistent comparisons.", "category": "system-monitoring", "install": "curl -sSfL https:\/\/raw.githubusercontent.com\/bootandy\/dust\/refs\/heads\/master\/install.sh | sh", "github": "https:\/\/github.com\/bootandy\/dust", "website": null, "source_url": null, "stars": 11362, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "linkerd", "name": "Linkerd CLI", "description": "Official Linkerd CLI for installing Linkerd on Kubernetes, injecting workloads, checking mesh health, and inspecting service traffic.", "long_description": "Linkerd is the command-line control surface for installing and operating the Linkerd service mesh on Kubernetes. It generates manifests for mesh lifecycle changes, inspects control plane and policy state, and exposes traffic, authorization, and multicluster workflows from the terminal.\n\n## What It Enables\n- Generate manifests to install, upgrade, prune, or uninstall Linkerd and its `viz` or multicluster extensions.\n- Inject or remove Linkerd sidecars in Kubernetes manifests, run preflight or runtime health checks, and inspect policy or endpoint state.\n- Query live mesh behavior with traffic stats, routes, taps, authorization views, and cross-cluster link resources.\n\n## Agent Fit\n- Many high-value commands support `--output json` or `jsonpath`, which makes follow-up parsing and verification practical in shell loops.\n- Most workflows are non-interactive and compose cleanly with `kubectl`, but the CLI assumes kubeconfig access and often a running Linkerd control plane or extension APIs.\n- Agents should prefer the JSON-capable subcommands over human helpers like `viz dashboard` and the termbox-based `viz top` view.\n\n## Caveats\n- Many lifecycle commands emit YAML or JSON for `kubectl apply` rather than mutating cluster state directly.\n- Traffic, authorization, and multicluster workflows depend on Linkerd already being installed, and some require optional extensions such as `viz`.", "category": "networking", "install": "curl --proto '=https' --tlsv1.2 -sSfL https:\/\/run.linkerd.io\/install-edge | sh", "github": "https:\/\/github.com\/linkerd\/linkerd2", "website": "https:\/\/linkerd.io\/2\/reference\/cli\/", "source_url": "https:\/\/linkerd.io", "stars": 11321, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Linkerd" }, { "slug": "streamlink", "name": "streamlink", "description": "Extract streams from websites and pipe them to a video player.", "long_description": "Extract streams from websites and pipe them to a video player. Streamlink is a CLI utility which pipes video streams from various services into a video player.\n\n## Highlights\n- Installs with `pip install streamlink`\n- Supports structured JSON or NDJSON output for machine-readable automation\n- Primary implementation language is Python\n\n## Agent Fit\n- Fits shell scripts and agent workflows that need a terminal-native interface\n- Machine-readable output makes it easier to inspect results, branch logic, and chain follow-up commands\n- Straightforward installation helps bootstrap local or ephemeral automation environments", "category": "media", "install": "pip install streamlink", "github": "https:\/\/github.com\/streamlink\/streamlink", "website": "https:\/\/streamlink.github.io\/", "source_url": null, "stars": 11318, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "opencode", "name": "OpenCode", "description": "Open-source terminal coding agent focused on fast local loops, tool orchestration, and AI-assisted development.", "long_description": null, "category": "agent-harnesses", "install": "npm install -g opencode-ai", "github": "https:\/\/github.com\/opencode-ai\/opencode", "website": "https:\/\/github.com\/opencode-ai\/opencode", "source_url": "https:\/\/github.com\/opencode-ai\/opencode", "stars": 11281, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": "OpenCode" }, { "slug": "convex", "name": "Convex CLI", "description": "Official Convex CLI for developing, deploying, and inspecting Convex backends, functions, data, and environment variables.", "long_description": "Convex CLI manages Convex backends from a local project directory. It handles dev syncing, deployment, function execution, data inspection, imports and exports, and environment management for cloud or local Convex deployments.\n\n## What It Enables\n- Push backend code during local development, regenerate generated types, and deploy functions, schema, and indexes to dev, prod, or preview deployments.\n- Run queries, mutations, and actions; tail logs; inspect table data; and read or update deployment environment variables from the shell.\n- Import or export deployment data, inspect function metadata, and start Convex's built-in MCP server when an editor or agent setup needs it.\n\n## Agent Fit\n- Commands map cleanly to inspect and change loops around an existing Convex project, so agents can deploy, run, inspect, and verify without leaving the shell.\n- Structured output exists where it matters, including `convex data --format jsonArray|jsonLines`, `convex logs --jsonl`, and JSON file output from `convex function-spec --file`.\n- Can also plug into MCP-based editor setups through the built-in `convex mcp start` server, but the direct CLI remains the primary action surface.\n\n## Caveats\n- You need a configured Convex project plus login or deploy-key credentials before most cloud commands can run unattended.\n- Some setup flows, especially first-run `convex dev` configuration and login, are interactive and tied to local project state.", "category": "databases", "install": "npm install convex", "github": "https:\/\/github.com\/get-convex\/convex-backend", "website": "https:\/\/docs.convex.dev\/cli", "source_url": null, "stars": 10739, "language": "TypeScript", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Convex" }, { "slug": "skopeo", "name": "skopeo", "description": "Daemonless container image CLI for inspecting, copying, signing, deleting, and syncing images across registries and OCI layouts.", "long_description": "Skopeo is a daemonless CLI for inspecting and moving container images across registries, archives, OCI layouts, and local container stores. It is built for registry-facing workflows like metadata inspection, image promotion, mirroring, signing, and trust verification.\n\n## What It Enables\n- Inspect remote image metadata, config, layers, and available tags without pulling the image or starting a container daemon.\n- Copy or sync images between registries, OCI layouts, archives, local directories, and container stores for promotion, mirroring, and air-gapped transfers.\n- Sign, verify, or delete images and enforce trust-policy checks as part of registry publishing or verification workflows.\n\n## Agent Fit\n- `inspect` and `list-tags` return structured JSON by default, so agents can query registries and branch on manifest or tag data directly.\n- The CLI exposes direct subcommands and flags instead of an interactive UI, and `login` supports `--password-stdin` for unattended auth flows.\n- Write-heavy paths such as `copy`, `sync`, `login`, and `delete` mostly communicate through exit status, logs, and optional digest files, so automation usually pairs them with follow-up inspection.\n\n## Caveats\n- Registry operations depend on credentials, TLS settings, and signature policy state, so unattended runs need that environment prepared first.\n- `delete` is registry-specific and can remove the underlying manifest behind multiple tags, not just the tag you named.", "category": "containers", "install": "brew install skopeo", "github": "https:\/\/github.com\/containers\/skopeo", "website": null, "source_url": "https:\/\/github.com\/containers\/skopeo", "stars": 10539, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Red Hat" }, { "slug": "pip", "name": "pip", "description": "Python package installer CLI for installing, upgrading, uninstalling, and inspecting packages in Python environments.", "long_description": "pip is the canonical CLI for installing and managing Python packages inside a specific interpreter or virtual environment. It resolves packages from indexes, requirements files, VCS URLs, local projects, and archives, and it can also inspect the resulting environment.\n\n## What It Enables\n- Install, upgrade, downgrade, and uninstall packages from PyPI, private indexes, requirements files, VCS URLs, local directories, or wheel and sdist archives.\n- Inspect installed distributions, dependency health, and available index versions before changing an environment.\n- Resolve requirements into machine-readable install reports and generate experimental `pylock.toml` lockfiles for reproducible workflow tooling.\n\n## Agent Fit\n- Works well in scripts and CI when the target interpreter is explicit, especially via `python -m pip` inside a chosen virtualenv.\n- Structured output is real but uneven: `pip inspect`, `pip list --format=json`, `pip index versions --json`, and `pip install --report` are machine-readable, while most install and repair flows are text-first.\n- Best fit for agents operating inside an existing Python environment, where pip becomes the direct inspect and change layer for package state.\n\n## Caveats\n- Installs can execute third-party build backends or setup code and mutate the selected environment, so unattended runs need trusted sources and guardrails.\n- `pip lock` is still experimental, and using the wrong `pip` binary can modify the wrong interpreter; automation should prefer `python -m pip`.", "category": "package-managers", "install": "python -m ensurepip --upgrade", "github": "https:\/\/github.com\/pypa\/pip", "website": "https:\/\/pip.pypa.io", "source_url": "https:\/\/pip.pypa.io", "stars": 10194, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "PyPA" }, { "slug": "oha", "name": "oha", "description": "HTTP load testing CLI for benchmarking APIs and web endpoints with concurrency, rate limits, and latency reports.", "long_description": "oha is an HTTP load-testing CLI for generating concurrent traffic against a URL or a file of URLs and summarizing how the server responded. It covers quick benchmark runs, rate-limited load checks, and live terminal monitoring.\n\n## What It Enables\n- Benchmark APIs or sites with fixed request counts or timed runs, tuning concurrency, QPS, burst behavior, keep-alive, HTTP version, headers, auth, and request bodies.\n- Measure latency percentiles, histograms, first-byte timing, throughput, and status-code distribution, then export summaries as JSON or per-request data as CSV.\n- Replay more realistic traffic mixes with URL lists or generated URL patterns, and optionally persist successful request records to SQLite for later analysis.\n\n## Agent Fit\n- Non-interactive flags, `--no-tui`, and structured JSON or CSV output make it easy to slot into CI checks, performance regressions, and agent verify loops.\n- The default ratatui monitor is a real fullscreen TUI for humans watching a run, but the code uses a faster collection path when TUI is disabled, which is the better automation mode.\n- Fit is strongest for inspect-only HTTP performance checks; it does not model browser execution or richer multi-step user journeys.\n\n## Caveats\n- `--output-format json` produces a summary document rather than per-request event records; use CSV or the SQLite sink when each request matters.\n- It operates at the raw HTTP request layer, so JavaScript execution, rendering, and browser-managed session behavior are outside scope.", "category": "testing", "install": "brew install oha", "github": "https:\/\/github.com\/hatoo\/oha", "website": null, "source_url": "https:\/\/github.com\/hatoo\/oha", "stars": 10097, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "velero", "name": "Velero", "description": "Kubernetes backup and disaster recovery CLI for creating, restoring, and managing cluster and volume backups.", "long_description": "Velero is a Kubernetes backup and disaster recovery CLI that installs and drives in-cluster controllers for backing up, restoring, and migrating cluster resources and persistent volume data. It covers the operational path from initial install and storage configuration to scheduled backups, restore execution, and repository maintenance.\n\n## What It Enables\n- Install Velero into a cluster, attach the right storage plugins, and configure object storage, snapshot locations, node agents, and maintenance settings from the terminal.\n- Create on-demand or scheduled backups with namespace, resource, and label filters, choose snapshot or file-system backup behavior, and protect cluster state before upgrades, migrations, or incident response work.\n- Inspect backup, restore, storage location, plugin, and backup repository objects, fetch operation logs, and run restores with namespace remapping or existing-resource update policies.\n\n## Agent Fit\n- Flag-driven commands, kubeconfig and namespace selection, wait flags, and create\/get flows make it workable in scripted backup and restore loops once cluster access already exists.\n- Key create, get, install, and location queries can emit JSON or YAML, but some important follow-up work still happens through plain-text describe output and streamed logs.\n- Best when a skill already knows the target cluster, storage backend, and safe restore scope, because the CLI mostly submits Kubernetes custom resources and then waits for asynchronous controllers to finish the real work.\n\n## Caveats\n- The CLI is only one part of the system: useful work depends on a running Velero deployment plus configured object storage or snapshot plugins and the right Kubernetes credentials.\n- Backup and restore actions are high impact, and file-system backup or node-agent setups can require privileged access and platform-specific tuning.", "category": "containers", "install": "brew install velero", "github": "https:\/\/github.com\/vmware-tanzu\/velero", "website": "https:\/\/velero.io\/docs\/", "source_url": "https:\/\/velero.io", "stars": 9866, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Velero" }, { "slug": "usql", "name": "usql", "description": "Universal SQL client for querying many databases with psql-style commands, scripts, and cross-database copy.", "long_description": "usql is a psql-inspired database shell that talks to many SQL backends through Go SQL drivers and dburl-style DSNs. It works as both an interactive client and a scriptable query runner when you need one command surface across heterogeneous databases.\n\n## What It Enables\n- Run ad hoc queries or SQL files against PostgreSQL, MySQL, SQLite, SQL Server, Oracle, and many other supported backends from one CLI.\n- Inspect schemas, tables, functions, indexes, and connection metadata with psql-style meta commands instead of learning each database's native client.\n- Copy query results between databases, or import CSV-backed data into a destination table, with `\\copy` and dburl DSNs.\n\n## Agent Fit\n- `-c`, `-f`, `--no-init`, `--no-password`, and `-q` give agents a workable non-interactive path once DSNs and credentials are already known.\n- `-J` enables JSON formatting for query results, but connection messages, errors, and some meta-command flows still come back as plain text.\n- Best for workflows that already know the target database and query shape; available drivers and metadata behavior vary by build tags and backend.\n\n## Caveats\n- Driver coverage depends on how the binary was built: plain `go install` includes base drivers, while release and Homebrew builds include more.\n- `\\copy` is not a drop-in clone of `psql`'s version and does not perform datatype conversion, so cross-database transfers may need explicit casts.", "category": "databases", "install": "brew install xo\/xo\/usql", "github": "https:\/\/github.com\/xo\/usql", "website": null, "source_url": null, "stars": 9852, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "serve", "name": "serve", "description": "Static file server CLI for previewing local sites, SPAs, and directories over HTTP or HTTPS.", "long_description": "serve is Vercel's CLI for quickly exposing a local directory, static site build, or single-page app over HTTP or HTTPS. It is mainly a lightweight local hosting primitive for previews, demos, browser tests, and LAN sharing rather than a broader deployment surface.\n\n## What It Enables\n- Serve a folder, static site build, or single-page app from the terminal for local preview and browser-based testing.\n- Bind the server to custom TCP ports, Unix sockets, Windows named pipes, or HTTPS endpoints, with optional CORS, compression, and SPA rewrites.\n- Share a directory with a built-in listing UI and `serve.json` configuration when you need a quick disposable web endpoint without setting up a full web server.\n\n## Agent Fit\n- Useful in automation when a workflow needs a deterministic local web server process before running HTTP checks or browser tests.\n- Flags are straightforward and non-interactive, but startup and request logs are plain text only, so verification usually happens over the served HTTP endpoint rather than by parsing CLI output.\n- Best as a supporting primitive inside local web-app loops, not as a rich inspect or mutate surface on its own.\n\n## Caveats\n- It is a long-running process, so unattended use needs process supervision and explicit port cleanup.\n- `serve.json` is configuration input, not a machine-readable output mode.", "category": "dev-tools", "install": "npx serve", "github": "https:\/\/github.com\/vercel\/serve", "website": null, "source_url": null, "stars": 9831, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Vercel" }, { "slug": "miller", "name": "Miller", "description": "Record-processing CLI for filtering, transforming, aggregating, and converting CSV, TSV, JSON, and similar structured data.", "long_description": "Miller is a record-oriented data wrangling CLI for CSV, TSV, JSON, JSON Lines, YAML, and similar file formats. It sits between classic Unix text tools and custom scripts, letting you inspect, reshape, aggregate, and convert structured records directly in shell pipelines.\n\n## What It Enables\n- Convert between CSV, TSV, JSON, JSON Lines, YAML, DKVP, XTAB, markdown-tabular, and other record formats without losing field names.\n- Filter, sort, join, group, and aggregate records, or compute new fields with verbs like `put`, `filter`, `join`, and `stats1`.\n- Clean exports or logs, split output by key, and rewrite files in place or stream transformed records into downstream commands.\n\n## Agent Fit\n- stdin or file-based commands, predictable stdout, and Miller's internal `then` chaining make it easy to script inspect, transform, and verify loops.\n- Structured output is real rather than incidental: source-backed `--ojson` and `--ojsonl` flags let agents hand results to other tools without screen scraping.\n- Best used as local data-processing glue around service CLIs, reports, and logs; more complex transforms require careful use of format flags and Miller's DSL quoting.\n\n## Caveats\n- It does not talk to remote services on its own; its value comes from reshaping local files or the output of other commands.\n- Streaming is a strength, but the docs call out that some verbs such as `sort`, `tac`, and `stats1` retain more data in memory.", "category": "data-processing", "install": "brew install miller", "github": "https:\/\/github.com\/johnkerl\/miller", "website": "https:\/\/miller.readthedocs.io\/", "source_url": null, "stars": 9774, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "git-crypt", "name": "git-crypt", "description": "Git repository encryption CLI for transparently encrypting selected files and sharing access with collaborators.", "long_description": "git-crypt is a Git-focused encryption CLI that uses Git filters to keep selected files encrypted in the repository while decrypting them transparently in an unlocked working tree. It is built for mixed repositories where most content stays public but a few keys, credentials, or config files need protection.\n\n## What It Enables\n- Initialize a repository for transparent encryption, mark specific paths in `.gitattributes`, and keep those files encrypted in Git history while collaborators work with decrypted copies locally.\n- Unlock a cloned repository with GPG-managed access or a shared symmetric key, then lock it again to remove local decrypted access.\n- Audit which files are encrypted, detect files that were committed before encryption rules were in place, and restage fixed encrypted versions with `status --fix`.\n\n## Agent Fit\n- The command surface is small, explicit, and mostly non-interactive, so it works for scripted repo bootstrap and secret-handling workflows.\n- Structured output is weak: commands print human-readable status, and the source explicitly rejects the unfinished machine-output mode for `status`.\n- Best fit is repository setup and verification around a handful of sensitive files, not broad secret lifecycle automation.\n\n## Caveats\n- It protects file contents, not filenames, commit messages, or other repository metadata.\n- The project does not support revoking previously granted access, and the docs position it as a poor fit for encrypting most or all of a repository.", "category": "security", "install": "brew install git-crypt", "github": "https:\/\/github.com\/AGWA\/git-crypt", "website": "https:\/\/www.agwa.name\/projects\/git-crypt\/", "source_url": "https:\/\/github.com\/AGWA\/git-crypt", "stars": 9489, "language": "C++", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "lf", "name": "lf", "description": "Terminal file manager for navigating directories, selecting files, and running shell-integrated file actions.", "long_description": "lf is a fullscreen terminal file manager for browsing directories, marking files, previewing content, and handing paths back to the shell or other commands. It is aimed at keyboard-driven local filesystem work rather than headless automation.\n\n## What It Enables\n- Browse large directory trees, jump between locations, mark files, and perform copy, move, rename, delete, and open workflows from one terminal UI.\n- Return the last visited directory to the shell or export selected file paths, which makes lf usable as a `cd` helper or interactive file picker.\n- Send commands to running lf clients and query state such as visible files, history, jumps, mappings, or custom commands through the built-in server.\n\n## Agent Fit\n- The command surface is stable and shell-friendly for wrapper workflows like `lf -print-last-dir`, `lf -print-selection`, and `lf -remote` queries.\n- All useful exported state is plain text, and the primary experience is a fullscreen TUI, so unattended parsing and control are limited.\n- Best fit is paired workflows where an agent or script cooperates with a human-operated file manager session rather than replacing it.\n\n## Caveats\n- Most functionality assumes an interactive terminal session; the headless server is mainly for coordinating clients and remote commands, not full standalone file automation.\n- Shell `cd` integration depends on helper scripts from `etc\/` rather than the `lf` binary alone.", "category": "file-management", "install": "env CGO_ENABLED=0 go install -ldflags=\"-s -w\" github.com\/gokcehan\/lf@latest", "github": "https:\/\/github.com\/gokcehan\/lf", "website": null, "source_url": null, "stars": 9110, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "tshark", "name": "TShark", "description": "Command-line packet analyzer for capturing, filtering, decoding, and exporting live or saved network traffic.", "long_description": "TShark is Wireshark's command-line packet analyzer for live captures and saved trace files. It exposes Wireshark's dissectors and filtering engine through flags, stdout, and capture files that fit shell-driven network debugging.\n\n## What It Enables\n- Capture traffic on chosen interfaces, apply capture or display filters, and write rolling `pcap` or `pcapng` files for incident evidence and later analysis.\n- Read saved or compressed traces, print packet summaries or full protocol trees, and extract selected fields or statistics from network traffic.\n- Export decoded packets as JSON, raw-packet JSON, EK NDJSON, CSV-like field output, or XML for downstream parsing, Elasticsearch ingest, or follow-up tooling.\n\n## Agent Fit\n- Real machine-readable output exists through `-T json`, `jsonraw`, `ek`, and `fields`, with `-j` or `-J` protocol filters and `--no-duplicate-keys` to narrow or normalize output.\n- Non-interactive flags, `-l` line buffering, interface and link-type discovery, and documented exit codes make it workable in inspect, capture, and verify loops.\n- Live capture still needs permissions and network-specific judgment, and decoded output can be large enough that agents usually need tight filters or a capture-first workflow.\n\n## Caveats\n- Live capture depends on `dumpcap` privileges or access to capture devices; the README explicitly discourages running `tshark` itself as root.\n- Verbose decode and JSON modes can explode in size on busy traces, so automation is usually safer when it saves captures first and re-reads them with narrower filters.", "category": "networking", "install": "brew install wireshark", "github": "https:\/\/github.com\/wireshark\/wireshark", "website": "https:\/\/www.wireshark.org\/docs\/man-pages\/tshark.html", "source_url": "https:\/\/www.wireshark.org\/docs\/man-pages\/tshark.html", "stars": 9048, "language": "C", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Wireshark" }, { "slug": "kubeseal", "name": "kubeseal", "description": "Kubernetes CLI for sealing Secret manifests into encrypted SealedSecret resources for GitOps workflows.", "long_description": "kubeseal is the client CLI for Sealed Secrets, turning Kubernetes Secret manifests or raw secret values into SealedSecret resources that only the target cluster's controller can decrypt. It is mainly a GitOps packaging tool for getting secret material into git safely, not a general secret manager.\n\n## What It Enables\n- Encrypt Secret manifests into SealedSecret JSON or YAML that can be committed to git and later applied to a cluster without exposing the plaintext secret.\n- Fetch the controller certificate, seal individual raw values, and merge new encrypted keys into an existing SealedSecret without needing the other cleartext values again.\n- Validate sealed secrets against the cluster, re-encrypt them to the latest sealing key, and recovery-unseal them from backed-up private keys during disaster recovery.\n\n## Agent Fit\n- The CLI is non-interactive by default, works well with stdin and stdout, and exposes explicit flags that fit cleanly into `kubectl`, CI, and GitOps pipelines.\n- Default JSON output and optional YAML output make the generated SealedSecret resources easy to pass to follow-up shell steps, even though the tool is more about manifest generation than rich inspection.\n- Best used as a narrow action primitive inside skills that prepare manifests, rotate sealing keys, or verify sealed secrets before commit or deploy.\n\n## Caveats\n- Most workflows depend on access to the Sealed Secrets controller or a previously fetched certificate, and custom controller names or namespaces need matching flags or environment variables.\n- Name, namespace, and sealing scope are part of the encryption model, so automation has to keep those values consistent, especially in raw mode.", "category": "security", "install": "brew install kubeseal", "github": "https:\/\/github.com\/bitnami-labs\/sealed-secrets", "website": "https:\/\/sealed-secrets.netlify.app", "source_url": "https:\/\/github.com\/bitnami-labs\/sealed-secrets", "stars": 8950, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Bitnami" }, { "slug": "visidata", "name": "VisiData", "description": "Terminal spreadsheet for exploring, cleaning, and reshaping CSV, JSON, SQLite, Excel, and other tabular data.", "long_description": "VisiData is a fullscreen terminal spreadsheet for exploring and editing structured data from files, databases, and other sources. It is strongest for tabular inspection and cleanup work you want to do inside the shell, then optionally replay in batch.\n\n## What It Enables\n- Open CSV, TSV, JSON, SQLite, Excel, and many other structured sources in one terminal view for ad hoc inspection.\n- Filter, sort, group, join, pivot, and edit rows or columns to clean or reshape tabular datasets.\n- Replay saved cmdlogs in batch mode and export the resulting sheet as TSV, JSON, JSONL, or other supported formats.\n\n## Agent Fit\n- Useful once a workflow has been captured: `--play`, `--batch`, and `-o` let an agent rerun repeatable table-cleaning or conversion steps.\n- Machine-readable output is available through save formats like JSON and JSONL, but the primary interface is still a fullscreen TUI.\n- Best fit for inspect, clean, and export loops where a human or earlier run teaches the keystroke workflow first.\n\n## Caveats\n- Most commands are exposed as keystrokes and sheet actions rather than stable verb-style subcommands, which makes one-off unattended use less discoverable.\n- Some loaders and sources need extra Python modules beyond the base install.", "category": "data-processing", "install": "pip3 install visidata", "github": "https:\/\/github.com\/saulpw\/visidata", "website": "https:\/\/visidata.org\/docs", "source_url": null, "stars": 8875, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "release-it", "name": "release-it", "description": "Release orchestration CLI for versioning, changelogs, git tags, GitHub or GitLab releases, and npm publishing.", "long_description": "release-it is a release orchestration CLI for source repositories that calculates the next version, shows changelog context, and runs the git, registry, and hosting steps around a release. It is most useful when you want one command to coordinate version bumps, tags, publishes, and hosted release creation from repo-local config.\n\n## What It Enables\n- Preview the next version or release notes, then run version bumps, commits, tags, and pushes from repo state.\n- Publish npm packages and create or update GitHub or GitLab releases, including release notes, assets, drafts, prereleases, and issue or PR comments.\n- Customize the release pipeline with hooks and plugins to run build steps, alternate changelog generators, other registries, or custom version sources.\n\n## Agent Fit\n- `--ci`, `--dry-run`, `--release-version`, and `--changelog` make it workable in inspect\/change\/verify loops before mutating a repo.\n- Most output is plain text and stdout previews rather than structured JSON, so downstream parsing is limited to exit status and a few printed values.\n- Best for agents already operating inside a release repo with credentials and project config in place; otherwise the default prompt flow and side effects need careful staging.\n\n## Caveats\n- Default mode is interactive, and publish or release steps may require GitHub, GitLab, or npm credentials and sometimes OTP input.\n- It is repo-local orchestration rather than a hosted release service, so correctness depends on tags, branch policy, and the target project's `release-it` configuration.", "category": "github", "install": "npm init release-it", "github": "https:\/\/github.com\/release-it\/release-it", "website": null, "source_url": "https:\/\/release-it.github.io\/", "stars": 8871, "language": "JavaScript", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "progress", "name": "progress", "description": "CLI for showing progress, throughput, and ETA for already-running copy, archive, compression, and checksum commands.", "long_description": "progress inspects already-running local processes and estimates how far file-oriented commands have advanced by reading open-file positions. It is mainly used to watch copy, archive, compression, checksum, and transfer jobs that were started without their own progress display.\n\n## What It Enables\n- See percent complete, bytes processed, throughput, and ETA for long-running local copy, move, archive, compression, checksum, or transfer-related jobs.\n- Target one process or class of processes with `-p`, `-c`, `-a`, and `-o` instead of scanning every known command on the system.\n- Keep a live terminal view while background file operations finish, or run a one-shot check to confirm a job is still moving.\n\n## Agent Fit\n- Useful in local inspect-and-verify loops because it can attach to an existing PID or command name without changing how the original job was started.\n- Automation is limited by plain-text output only; no JSON mode or other stable machine-readable schema is implemented.\n- Best as a sidecar for long-running shell jobs on the same host, not as a broader action CLI for managing files or services.\n\n## Caveats\n- Coverage depends on what the tool can infer from `\/proc`, `libproc`, or `procstat`, so permissions and file-access patterns can hide or distort progress.\n- Continuous monitor modes switch to an ncurses screen, which is convenient for humans but less convenient for unattended parsing.", "category": "utilities", "install": "brew install progress", "github": "https:\/\/github.com\/Xfennec\/progress", "website": null, "source_url": "https:\/\/github.com\/Xfennec\/progress", "stars": 8827, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "buildah", "name": "Buildah", "description": "Daemonless CLI for building, inspecting, and publishing OCI container images from Containerfiles or working containers.", "long_description": "Buildah is a daemonless CLI for building OCI container images from Containerfiles, remote build contexts, or manually assembled working containers. It focuses on the build path: create a working container, modify its filesystem and image config, inspect the result, then commit or push it.\n\n## What It Enables\n- Build OCI or Docker-format images from Containerfiles, Git or URL build contexts, or scratch without depending on a long-running Docker daemon.\n- Create working containers from base images, run build steps inside them, copy files, change image metadata, mount the root filesystem, then commit the result into a reusable image.\n- Inspect local images, containers, manifests, and host storage details, and push finished images or manifest lists to registries.\n\n## Agent Fit\n- Several read paths are machine-readable: `inspect` emits JSON by default, `info` returns JSON unless templated, and `images`, `containers`, `mount`, `version`, and `manifest inspect` support JSON output.\n- Commands map cleanly to inspect\/change\/verify loops in CI or agent workflows because the core build, config, copy, commit, push, and inspect operations are direct shell subcommands rather than an interactive UI.\n- Fit is strongest on Linux build hosts with container storage already configured; rootless mounts may require `buildah unshare`, and registry auth or storage-driver issues can interrupt unattended runs.\n\n## Caveats\n- Upstream docs describe Buildah as Linux-focused, and the tutorial says it is not supported on Windows or Mac platforms.\n- The project is primarily an image builder, not the main runtime surface for long-lived containers; the README and tutorial direct broader runtime workflows to `podman`.", "category": "containers", "install": "sudo dnf -y install buildah", "github": "https:\/\/github.com\/containers\/buildah", "website": "https:\/\/buildah.io", "source_url": "https:\/\/buildah.io", "stars": 8662, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Red Hat" }, { "slug": "pdm", "name": "PDM", "description": "Python workflow CLI for locking dependencies, syncing environments, running project scripts, and managing Python interpreters.", "long_description": "PDM is a Python packaging workflow CLI that manages `pyproject.toml`, resolves and locks dependencies, syncs project environments, and can build or publish distributions. It also handles interpreter selection, managed Python installs, and project task running from the same command surface.\n\n## What It Enables\n- Create or migrate Python projects, declare dependencies in `pyproject.toml`, lock them, and sync the environment to the lockfile.\n- Select or install Python interpreters, create per-project environments, and inspect the active interpreter or package state.\n- Run project scripts, export lock data to `requirements.txt` or `pylock.toml`, and build or publish packages without switching tools.\n\n## Agent Fit\n- Several inspect surfaces are machine-readable, including `pdm info --json`, `pdm list --json`, `pdm outdated --json`, and `pdm run --json` for task metadata.\n- Core workflows are non-interactive once a project is configured, which makes `lock`, `sync`, `export`, `run`, and `publish` workable in CI or agent loops.\n- Some setup paths still prompt by default, especially `pdm new` and interpreter selection in `pdm use`, so unattended runs need explicit flags or preconfigured project state.\n\n## Caveats\n- It is tightly coupled to Python packaging conventions and project files, so its value is strongest inside Python repos rather than as a general system package manager.\n- Commands that install interpreters, resolve dependencies, or publish packages depend on network access and can mutate local environments or package indexes.", "category": "package-managers", "install": "curl -sSL https:\/\/pdm-project.org\/install.sh | bash", "github": "https:\/\/github.com\/pdm-project\/pdm", "website": "https:\/\/pdm-project.org", "source_url": "https:\/\/pdm-project.org", "stars": 8540, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "checkov", "name": "Checkov", "description": "Security scanner CLI for Terraform, Kubernetes, Dockerfiles, CI configs, and other infrastructure-as-code files.", "long_description": "Checkov is a security scanning CLI for infrastructure-as-code and adjacent delivery config such as CI pipelines, Dockerfiles, and Kubernetes manifests. It scans repos, directories, files, or Terraform plan JSON to flag misconfigurations, secrets, and policy violations before deploy.\n\n## What It Enables\n- Scan Terraform, CloudFormation, Kubernetes, Helm, Dockerfiles, GitHub Actions, GitLab CI, and other supported config files from a file, directory, or plan export.\n- Emit JSON, SARIF, JUnit XML, CycloneDX, CSV, or console reports for CI gates, code-scanning uploads, and follow-up parsing.\n- Tune or extend policy coverage with framework filters, skip or allow lists, baselines, custom policies, and external check packs from trusted local or Git sources.\n\n## Agent Fit\n- Non-interactive scan commands, real JSON output, and explicit pass or fail controls via `--soft-fail`, `--soft-fail-on`, and `--hard-fail-on` work well in automation.\n- It fits inspect-edit-rerun loops cleanly: an agent can scope by file or framework, parse findings, change IaC, then rerun the same command for verification.\n- Fit is weaker for some SCA and Prisma Cloud workflows because package or image scanning and platform metadata features can require API keys and network access.\n\n## Caveats\n- Scanning every framework in a large repo can be noisy or slow, so unattended use usually needs `--framework`, `--check`, or skip filters.\n- External checks loaded from directories or Git repositories can execute Python code, so only trusted policy sources are safe.", "category": "security", "install": "pip install checkov", "github": "https:\/\/github.com\/bridgecrewio\/checkov", "website": "https:\/\/www.checkov.io\/", "source_url": "https:\/\/www.checkov.io\/", "stars": 8510, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Bridgecrew" }, { "slug": "shfmt", "name": "shfmt", "description": "Shell formatter CLI for reformatting and syntax-checking Bash, POSIX, mksh, bats, and zsh scripts.", "long_description": "shfmt is a shell formatter for normalizing script layout across repos, CI, and editor workflows. It also walks directories, detects shell files by extension or shebang, and can parse scripts into a typed shell AST.\n\n## What It Enables\n- Reformat shell scripts consistently across a repo, write fixes in place, or show diffs and changed-file lists for CI and pre-commit checks.\n- Find shell scripts recursively and validate syntax across Bash, POSIX sh, mksh, bats, and zsh without depending on a particular runtime shell.\n- Convert shell source to a typed JSON syntax tree, transform or inspect it, and print it back to shell code with `--from-json`.\n\n## Agent Fit\n- The core commands are non-interactive, deterministic, and easy to compose in edit-then-verify loops for shell code changes.\n- Repo-wide runs, stdin support, explicit exit failures on diffs or parse errors, and EditorConfig handling make it practical in scripts, CI, and automated refactors.\n- Structured output exists, but mainly as an AST via `--to-json`; normal formatting and directory-walk flows still return plain text paths, diffs, and errors.\n\n## Caveats\n- Formatting is intentionally opinionated, with limited style knobs and no support for disabling formatting on selected line ranges.\n- `--to-json` only works with stdin, so machine-readable output is not the default interface for batch formatting runs.", "category": "dev-tools", "install": "go install mvdan.cc\/sh\/v3\/cmd\/shfmt@latest", "github": "https:\/\/github.com\/mvdan\/sh", "website": "https:\/\/pkg.go.dev\/mvdan.cc\/sh\/v3\/cmd\/shfmt", "source_url": "https:\/\/pkg.go.dev\/mvdan.cc\/sh\/v3", "stars": 8510, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "syft", "name": "syft", "description": "SBOM generation CLI for container images, filesystems, and archives, with SPDX and CycloneDX output.", "long_description": "Syft generates software bill of materials from container images, filesystem paths, archives, and other OCI sources. It is built for software supply chain inspection workflows where you need package inventories you can export, compare, or pass to downstream scanners and compliance systems.\n\n## What It Enables\n- Scan container images from Docker, Podman, registries, tar archives, OCI layouts, directories, or single files to inventory packages and selected file metadata.\n- Export SBOMs as Syft JSON, SPDX, CycloneDX, text, table, purl, or custom template output for CI, audits, and downstream tooling.\n- Convert existing SBOMs between Syft, SPDX, and CycloneDX formats, and attach signed SBOM attestations to container images.\n\n## Agent Fit\n- Flag-driven commands and explicit source schemes like `registry:`, `docker-archive:`, `oci-dir:`, `dir:`, and `file:` make unattended scans and follow-up retries predictable.\n- `-o json`, `spdx-json`, and `cyclonedx-json` provide machine-readable output, and the repo ships versioned JSON schemas plus schema tests for Syft JSON.\n- Best for inspect and export loops rather than broad mutation workflows; registry or daemon access affects what an agent can scan, and attestation adds external `cosign` and registry requirements.\n\n## Caveats\n- Default output is a human table, so automation should always request an explicit JSON or SBOM format.\n- `syft attest` is limited to OCI registry images and requires `cosign` on PATH.", "category": "security", "install": "curl -sSfL https:\/\/get.anchore.io\/syft | sudo sh -s -- -b \/usr\/local\/bin", "github": "https:\/\/github.com\/anchore\/syft", "website": "https:\/\/oss.anchore.com\/docs\/reference\/syft\/cli\/", "source_url": null, "stars": 8454, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Anchore" }, { "slug": "wego", "name": "wego", "description": "Terminal weather CLI for current conditions and multi-day forecasts from pluggable weather providers.", "long_description": "wego is a terminal weather client that fetches current conditions and short forecasts from several weather providers and can render them as ASCII tables, markdown, emoji, or JSON. It is a read-only utility for shell-based forecast checks rather than a broader service-management CLI.\n\n## What It Enables\n- Fetch current weather and 1 to 7 day forecasts for a chosen location from supported providers such as OpenWeatherMap, Open-Meteo, SMHI, or Caiyun.\n- Render forecast data as terminal-friendly ASCII tables, markdown, emoji, or structured JSON depending on whether a human or a script is consuming the result.\n- Swap providers or feed saved forecast JSON back through the `json` backend for testing, templating, or repeatable output flows.\n\n## Agent Fit\n- Useful for simple inspect loops because it is non-interactive after setup, accepts flags for location, days, units, backend, and frontend, and can return structured JSON through the JSON frontend.\n- Automation scope is narrow and read-only: it fetches forecast data but does not control any external service beyond those weather requests.\n- Best fit is lightweight shell automation or context gathering where an agent needs quick weather data, not a deep workflow surface.\n\n## Caveats\n- The README setup mostly documents older API-keyed backends, so source and `--help` are more reliable than the setup section when choosing a backend.\n- The default backend still expects an OpenWeatherMap API key, so first-run usage is smoother when you pass an alternate backend explicitly or preconfigure the CLI.", "category": "utilities", "install": "go install github.com\/schachmat\/wego@latest", "github": "https:\/\/github.com\/schachmat\/wego", "website": null, "source_url": null, "stars": 8408, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "pup", "name": "pup", "description": "HTML query CLI for selecting nodes with CSS selectors and emitting matching markup, text, attributes, or JSON.", "long_description": "pup is a small HTML parsing CLI that reads markup from stdin or a file, applies CSS selectors, and prints the matching nodes. It is useful for lightweight scraping, inspection, and preprocessing when you already have the HTML and do not need a browser session.\n\n## What It Enables\n- Extract specific HTML fragments, text content, attribute values, or match counts from fetched pages or saved documents.\n- Turn selected nodes into a simple JSON structure for downstream parsing in shell pipelines.\n- Pretty-print messy markup or narrow a large page down to the subsection another tool or script should inspect next.\n\n## Agent Fit\n- Stdin or file input, explicit flags, and selector-based queries make it easy to compose with `curl`, saved fixtures, and follow-up shell steps.\n- `json{}` provides real machine-readable output, but the schema is limited to node tags, attributes, text, comments, and nested children.\n- Best as a lightweight HTML extraction primitive inside a larger fetch and parse workflow, not as a complete web interaction surface.\n\n## Caveats\n- It only processes static HTML you provide; it does not fetch pages, run JavaScript, or maintain login state.\n- The project README has at least one stale behavior note around `json{}` output shape, so source is a better reference for edge cases.", "category": "data-processing", "install": "brew install https:\/\/raw.githubusercontent.com\/EricChiang\/pup\/master\/pup.rb", "github": "https:\/\/github.com\/ericchiang\/pup", "website": null, "source_url": "https:\/\/github.com\/ericchiang\/pup", "stars": 8399, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "conventional-changelog", "name": "conventional-changelog CLI", "description": "Generate changelog and release note markdown from conventional commits, semver tags, and repository metadata.", "long_description": "conventional-changelog turns git history into release notes and `CHANGELOG.md` entries using conventional commit presets and repository metadata. It is a focused changelog generator, not a full release orchestration tool.\n\n## What It Enables\n- Generate changelog sections from commits since the last semver tag, then print to stdout or merge the result into `CHANGELOG.md`.\n- Regenerate full history or limit output to recent releases, unreleased work, specific tag prefixes, lerna package tags, or a subdirectory inside a repo.\n- Load presets, config modules, and context JSON to adapt headings, links, and release note structure to a project's conventions.\n\n## Agent Fit\n- Non-interactive flags, stdout support, and predictable file-writing modes fit CI jobs and inspect-change-verify loops around release preparation.\n- Output is markdown only, so downstream automation gets human-readable release notes rather than structured JSON.\n- Best when an agent already controls the repo, tags, and commit conventions and needs deterministic changelog generation inside a larger release workflow.\n\n## Caveats\n- Output quality depends heavily on disciplined commit messages and semver tags; messy history produces weak changelogs.\n- It only generates changelog content, so version bumps, tagging, and publishing still need companion scripts or tools.", "category": "github", "install": "npm i conventional-changelog", "github": "https:\/\/github.com\/conventional-changelog\/conventional-changelog", "website": null, "source_url": "https:\/\/github.com\/conventional-changelog\/conventional-changelog", "stars": 8398, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "amtool", "name": "amtool", "description": "Alertmanager CLI for querying alerts, managing silences, testing routes, and validating configs.", "long_description": "amtool is the command line client for Prometheus Alertmanager. It lets you inspect live alert state, manage silences, and check how Alertmanager config, routing, and notification templates will behave before or during operations work.\n\n## What It Enables\n- Query active, inhibited, silenced, or unprocessed alerts with Alertmanager matcher syntax, including JSON output for scripting against current incident state.\n- Create, update, expire, and bulk import silences, with filters for creator, ID, expiry window, and label matchers.\n- Validate config files, render notification templates with example or JSON data, and inspect or test routing trees against a local config file or a running Alertmanager.\n\n## Agent Fit\n- Structured output is available on key read commands through `-o json`, which makes alert, silence, config, and cluster queries straightforward to parse in shell loops.\n- Most commands are non-interactive once `--alertmanager.url` or config defaults are set, and the matcher-based filters compose well with pipelines and follow-up commands.\n- Best fit is operating an existing Alertmanager deployment or verifying alerting config changes; it is a focused control surface, not a full incident system by itself.\n\n## Caveats\n- Many actions require a reachable Alertmanager API plus any needed HTTP auth or TLS config; only config checks, local route tests, and template rendering work fully offline.\n- Direct `alert add` exists, but the docs note that Alertmanager normally expects Prometheus or another client to resend alerts reliably, so manual alert injection is more of an advanced workflow than the default model.", "category": "system-monitoring", "install": "go install github.com\/prometheus\/alertmanager\/cmd\/amtool@latest", "github": "https:\/\/github.com\/prometheus\/alertmanager", "website": "https:\/\/prometheus.io", "source_url": "https:\/\/prometheus.io\/docs\/alerting\/latest\/clients\/", "stars": 8380, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Prometheus" }, { "slug": "iperf3", "name": "iperf3", "description": "Network throughput testing CLI for measuring TCP, UDP, and SCTP bandwidth, loss, and jitter between hosts.", "long_description": "iperf3 is an active network throughput testing CLI that runs as either a client or a server to measure TCP, UDP, or SCTP path performance between two hosts. It is built for bandwidth and transport diagnostics, not passive monitoring.\n\n## What It Enables\n- Measure upload or download throughput, transfer rates, retransmits, loss, and jitter between a client and a reachable `iperf3` server.\n- Run repeatable TCP, UDP, or SCTP tests with control over duration, bitrate, parallel streams, buffer sizes, reverse mode, and one-off server behavior.\n- Capture client-side and server-side test results for incident response, capacity checks, network tuning, or post-change verification.\n\n## Agent Fit\n- The CLI is non-interactive and flag-driven, so it works cleanly in scripts, CI checks, and inspect or verify loops.\n- Real machine-readable output exists: `-J` emits a full JSON result object, and `--json-stream` can emit line-delimited JSON during long tests.\n- Best fit for agents that already control both ends of a path or can target an existing test server; it measures network performance but does not discover or fix the underlying cause.\n\n## Caveats\n- You need an `iperf3` server or another managed endpoint on the far side; it is not a passive local-only inspection tool.\n- iperf3 is not backward compatible with iperf2, so both ends need the iperf3 protocol.", "category": "networking", "install": "brew install iperf3", "github": "https:\/\/github.com\/esnet\/iperf", "website": "https:\/\/software.es.net\/iperf\/", "source_url": "https:\/\/software.es.net\/iperf\/", "stars": 8306, "language": "C", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "ESnet" }, { "slug": "scc", "name": "scc", "description": "Code metrics CLI for counting files, lines, comments, complexity, ULOC, and estimated cost across source trees.", "long_description": "scc is a source code metrics CLI for scanning directories and summarizing language mix, line counts, complexity estimates, duplicate handling, and cost-style estimates across many programming languages.\n\n## What It Enables\n- Measure language mix, file counts, code\/comment\/blank lines, and processed bytes for a repository or set of directories.\n- Sort per-file results to find the largest or most complex files, and optionally account for duplicates, minified files, generated files, or oversized files before deeper review.\n- Export repo metrics as JSON, CSV, HTML, SQL, or OpenMetrics for CI jobs, dashboards, or follow-up scripts.\n\n## Agent Fit\n- JSON and JSON2 output, stable flags, and stdout or file-based reporting make it easy to drop into inspect-parse-report loops.\n- Ignore-file support, extension filters, per-file mode, and `--format-multi` work well for automated repo audits and CI reporting.\n- This is inspection-only, and its complexity and COCOMO outputs are heuristics, so agents should treat them as prioritization signals rather than authoritative code-quality judgments.\n\n## Caveats\n- The complexity metric is a fast file-level approximation based on token matching, not parsed AST analysis.\n- ULOC and DRYness calculations add extra work; the README warns they can significantly increase runtime on large trees.", "category": "dev-tools", "install": "go install github.com\/boyter\/scc\/v3@latest", "github": "https:\/\/github.com\/boyter\/scc", "website": null, "source_url": null, "stars": 8158, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "grex", "name": "grex", "description": "Regex generation CLI that turns sample strings into a regular expression, with flags for anchors, character classes, and repetition handling.", "long_description": "grex is a CLI and library for generating a single regular expression from example strings. It is most useful for bootstrapping patterns from known test cases rather than hand-authoring or debugging full regex logic from scratch.\n\n## What It Enables\n- Turn sample strings from arguments, stdin, or a file into one regex that matches those cases.\n- Generalize the output with flags for word, digit, or whitespace classes, repeated substrings, case-insensitive matching, capture groups, and optional anchors.\n- Emit readable or colorized regex text that can be pasted into code, config, tests, or follow-up shell commands.\n\n## Agent Fit\n- Non-interactive flags plus stdin and file input make it straightforward to call from scripts when an agent needs a starter pattern.\n- Output is plain regex text with no JSON schema, so follow-up automation depends on the agent already knowing where to insert or test that pattern.\n- Best for narrow text-processing and code-generation steps, not for inspecting external systems or replacing regex review.\n\n## Caveats\n- The project explicitly warns that generated regexes should still be inspected by hand and may need engine-specific simplification or tuning.\n- Options such as `\\w`, `\\d`, `\\s`, or repetition conversion can widen matches beyond the original examples if used carelessly.", "category": "utilities", "install": "brew install grex", "github": "https:\/\/github.com\/pemistahl\/grex", "website": "https:\/\/pemistahl.github.io\/grex-js\/", "source_url": null, "stars": 8062, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "nb", "name": "nb", "description": "Plain-text knowledge base CLI for creating, searching, browsing, and syncing notes, bookmarks, and todos.", "long_description": "`nb` is a plain-text notebook CLI for managing local notes, bookmarks, todos, folders, and multiple notebooks from the shell. It stores content as normal files, adds Git-backed history and sync, and can serve a local web view for browsing linked notes and archived pages.\n\n## What It Enables\n- Create, tag, move, and search notes, folders, todos, and notebooks while keeping everything in normal Markdown or other local files.\n- Save URLs as bookmark files with extracted page metadata and cached page content, then search archived pages locally or open them in terminal or GUI browsers.\n- Browse linked notes through the local web app, export content through Pandoc, and sync notebook repositories through Git remotes.\n\n## Agent Fit\n- Plain-text storage plus flags like `show --print`, `show --path`, `list --paths`, and `search --list` make inspect, edit, and verify loops workable from scripts.\n- Search, listing, note creation, notebook selection, and sync commands are non-interactive when fully specified, but output is plain text and no JSON mode was found.\n- Best fit is a local knowledge base that an agent can script around; browser views, pagers, terminal web browsers, encryption prompts, and Git credentials make unattended automation less clean.\n\n## Caveats\n- `browse` depends on `pandoc` plus `ncat` or `socat`, and richer terminal rendering relies on optional tools like `w3m`, `links`, or `bat`.\n- Some workflows default to human tools such as your editor, pager, GUI browser, or password prompts for encrypted notes and private Git remotes.", "category": "dev-tools", "install": "brew install xwmx\/taps\/nb", "github": "https:\/\/github.com\/xwmx\/nb", "website": "https:\/\/xwmx.github.io\/nb\/", "source_url": null, "stars": 8042, "language": "Shell", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "flux", "name": "Flux CLI", "description": "GitOps CLI for bootstrapping Flux on Kubernetes, managing Flux resources, and inspecting reconciliation state.", "long_description": "Flux CLI is the command line client for Flux, a GitOps toolkit for keeping Kubernetes clusters in sync with Git and OCI-sourced configuration. It bootstraps Flux onto clusters, manages Flux custom resources, and gives operators a shell surface for reconciliation, delivery checks, and manifest packaging.\n\n## What It Enables\n- Bootstrap Flux against GitHub, GitLab, Gitea, Bitbucket Server, or plain Git repositories, committing install and sync manifests as part of cluster setup.\n- Create, export, reconcile, suspend, resume, diff, and delete Flux sources, kustomizations, Helm releases, alerts, receivers, tenants, and image automation resources.\n- Check controller health, inspect events, logs, and resource trees, migrate Flux API versions, and push, pull, or list OCI artifacts that carry deployment manifests.\n\n## Agent Fit\n- The command set maps well to inspect-change-verify loops: `check`, `get`, `events`, `logs`, `tree`, `reconcile`, `diff`, and `export` can be chained around Kubernetes and GitOps automation.\n- Machine-readable output exists, but it is uneven: `version -o json`, `tree ... -o json`, and `push artifact -o json` are parseable, while many `get` and status commands still print tables or formatted logs.\n- Best fit for agents that already have kubeconfig, cluster RBAC, and repo or registry credentials; non-interactive flags like `--silent`, `--yes`, and `--export` help, but bootstrap, install, delete, and uninstall can still prompt by default.\n\n## Caveats\n- Useful operation depends on a reachable Kubernetes cluster plus repo or registry credentials, so the CLI is less self-contained than a hosted-service API client.\n- Many day-to-day inspect commands still return human-oriented tables or logs instead of consistent JSON, which adds parsing friction in unattended workflows.", "category": "containers", "install": "curl -s https:\/\/raw.githubusercontent.com\/fluxcd\/flux2\/main\/install\/flux.sh | sudo bash", "github": "https:\/\/github.com\/fluxcd\/flux2", "website": "https:\/\/fluxcd.io\/flux\/installation\/", "source_url": "https:\/\/fluxcd.io\/flux\/installation\/", "stars": 7922, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "dasel", "name": "dasel", "description": "CLI for querying, updating, and converting JSON, YAML, TOML, XML, CSV, HCL, and INI data with one selector syntax.", "long_description": "Dasel is a structured-data query and transformation CLI for formats such as JSON, YAML, TOML, XML, CSV, HCL, and INI. It gives you one selector language for reading values, rewriting documents, searching nested data, and converting between formats in shell pipelines.\n\n## What It Enables\n- Extract values, arrays, and nested matches from structured data across supported formats without switching tools.\n- Rewrite documents by assigning expressions in the query, then emit either the selected result or the updated root document.\n- Convert data between formats and pull file contents or variables into queries for config editing and data-wrangling workflows.\n\n## Agent Fit\n- Reads from stdin, writes to stdout, and exposes stable `--in`, `--out`, `--root`, and `--var` flags that fit inspect\/change\/verify loops.\n- JSON output is real output support, not just JSON input handling, so agents can normalize other formats into structured output for follow-up steps.\n- The default workflow is non-interactive and scriptable; the separate interactive mode is alpha and best treated as optional exploration rather than core automation surface.\n\n## Caveats\n- Editing files is usually done via pipes, redirection, or file-loaded variables rather than a dedicated in-place file flag.\n- The query language is Dasel-specific, so complex transforms may require a quick docs or `--help` pass before automating them.", "category": "data-processing", "install": "brew install dasel", "github": "https:\/\/github.com\/TomWright\/dasel", "website": "https:\/\/daseldocs.tomwright.me\/", "source_url": null, "stars": 7876, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "git-standup", "name": "git-standup", "description": "Git standup CLI for summarizing recent commits across one repo or a repo tree.", "long_description": "git-standup is a small shell wrapper around `git log` that turns recent commit history into standup-style summaries for the current repository or a directory tree of repositories. It is aimed at answering what you or a teammate changed since the last working day without hand-building log queries each time.\n\n## What It Enables\n- Summarize your own or another author's recent commits across the current repo or multiple repos under a workspace directory.\n- Filter standup output by date range, workweek, branch, GPG status, or diffstat when you need daily updates or lightweight activity audits.\n- Generate a plain-text standup report file and optionally fetch remotes first before collecting commit summaries.\n\n## Agent Fit\n- Non-interactive flags and simple shell usage make it easy to call from cron jobs, CI, or local status scripts.\n- Output is plain text only, so agents that need structured summaries must parse human-oriented `git log` formatting or call `git log` directly.\n- Best fit is quick status reporting across many local repos; it is less compelling as a general Git automation surface because it mostly packages existing `git log` filters.\n\n## Caveats\n- Reports only reflect local Git history unless you opt into `-f` fetches first.\n- The tool is intentionally narrow: it summarizes commits, but it does not add broader inspect-or-change workflows beyond optional fetches and report-file output.", "category": "github", "install": "brew install git-standup", "github": "https:\/\/github.com\/kamranahmedse\/git-standup", "website": null, "source_url": null, "stars": 7820, "language": "Shell", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "puppet", "name": "Puppet", "description": "Configuration management CLI for modeling desired system state and applying infrastructure changes reliably.", "long_description": "Configuration management CLI for modeling desired system state and applying infrastructure changes reliably. Server automation framework and application.\n\n## Highlights\n- Installs with `brew install puppetlabs\/puppet\/puppet-agent`\n- Primary implementation language is Ruby\n- Maintained by the upstream Puppet team\n\n## Agent Fit\n- Fits shell scripts and agent workflows that need a terminal-native interface\n- Straightforward installation helps bootstrap local or ephemeral automation environments", "category": "cloud", "install": "brew install puppetlabs\/puppet\/puppet-agent", "github": "https:\/\/github.com\/puppetlabs\/puppet", "website": "https:\/\/www.puppet.com\/docs\/puppet\/latest\/services_commands.html", "source_url": "https:\/\/www.puppet.com\/docs\/puppet\/latest\/services_commands.html", "stars": 7811, "language": "Ruby", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Puppet" }, { "slug": "xh", "name": "xh", "description": "HTTP client CLI for sending API requests, inspecting responses, downloading bodies, and reusing state with sessions.", "long_description": "xh is a command-line HTTP client for calling APIs and other HTTP services with HTTPie-style request syntax. It covers request construction, response inspection, downloads, sessions, and curl translation from one binary.\n\n## What It Enables\n- Send HTTP requests with methods, headers, query params, JSON or form fields, multipart uploads, stdin or file bodies, auth, proxies, TLS controls, HTTP version selection, and Unix sockets.\n- Inspect response headers, body, or metadata separately, follow redirects, build requests offline before sending them, and translate an `xh` command into `curl` when needed.\n- Download response bodies with resume support and reuse cookies, auth, and custom headers across repeated API calls with session files.\n\n## Agent Fit\n- The command surface is mostly flag-driven and non-interactive, and xh fails on unexpected HTTP status codes by default, which makes inspect or change or verify loops safer in unattended runs.\n- Output control is script-friendly through `--print`, `--body`, `--headers`, `--meta`, `--offline`, and `--ignore-stdin`, but machine-readability is still limited because there is no dedicated structured output mode.\n- Best used as a generic HTTP primitive when an agent already knows the target API and wants direct shell access rather than a higher-level service CLI.\n\n## Caveats\n- Output formatting changes when stdout is a TTY, so automation should usually pin flags like `--pretty=none`, `--print`, and `--ignore-stdin` for deterministic behavior.\n- Some auth paths can prompt for missing credentials, and session files persist cookies and auth material on disk.", "category": "http-apis", "install": "brew install xh", "github": "https:\/\/github.com\/ducaale\/xh", "website": null, "source_url": null, "stars": 7637, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "htmlq", "name": "htmlq", "description": "CLI for querying HTML with CSS selectors and extracting matching fragments, text, or attributes in shell pipelines.", "long_description": "htmlq is a small CLI for selecting parts of an HTML document with CSS selectors and sending the result to stdout. It is useful when a script or agent needs lightweight HTML extraction or cleanup without a browser session.\n\n## What It Enables\n- Extract matching elements, text content, or attribute values from HTML read from stdin or a file.\n- Strip unwanted nodes before output so downstream tools see only the fragment you care about.\n- Rewrite relative links against a supplied or detected base URL before passing results into later shell steps.\n\n## Agent Fit\n- CSS selectors plus stdin\/stdout make it easy to drop into fetch, inspect, and follow-up pipeline loops.\n- Output is deterministic plain text or HTML, but there is no JSON mode, so downstream parsing stays string-based.\n- Best for lightweight scraping and preprocessing of static HTML, not for broader browser automation or stateful web workflows.\n\n## Caveats\n- The feature surface is intentionally narrow: selection, text or attribute extraction, node removal, pretty printing, and link rewriting.\n- If a page needs JavaScript execution, login state, or form interaction, you need another tool before `htmlq` can help.", "category": "data-processing", "install": "brew install htmlq", "github": "https:\/\/github.com\/mgdm\/htmlq", "website": null, "source_url": "https:\/\/github.com\/mgdm\/htmlq", "stars": 7504, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "miniserve", "name": "miniserve", "description": "Local HTTP file server CLI for sharing, browsing, uploading, and downloading files and directories.", "long_description": "miniserve is a lightweight CLI for exposing a local file or directory over HTTP with an optional directory UI. It covers quick artifact sharing, temporary static hosting, and small dropbox-style file exchange without standing up a fuller web server.\n\n## What It Enables\n- Serve a local file or directory over HTTP for ad hoc sharing, downloads, or lightweight static-site hosting.\n- Turn on auth, TLS, random routes, custom headers, and route prefixes when a quick file share needs a bit more control.\n- Accept uploads, create or delete directories, offer on-the-fly tar or zip downloads, and expose read-only WebDAV for remote access to the served tree.\n\n## Agent Fit\n- Startup is simple and non-interactive, so agents can reliably bring up a local file server with the needed flags and environment variables.\n- There is no general `--json` or structured CLI output mode; after launch, most follow-up work happens through HTTP endpoints or WebDAV rather than machine-readable command output.\n- Best fit is artifact handoff and temporary exposure of local files to browsers, curl, or other tools, not rich state inspection through the CLI itself.\n\n## Caveats\n- Uploads, deletes, archive downloads, and WebDAV are opt-in features, so unattended workflows need the right flags and path restrictions up front.\n- `--enable-zip` can exhaust memory on large directories because zip archives are generated in memory.", "category": "utilities", "install": "brew install miniserve", "github": "https:\/\/github.com\/svenstaro\/miniserve", "website": null, "source_url": null, "stars": 7438, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "translate-shell", "name": "translate-shell", "description": "Command-line translator for text, files, and web pages using Google, Bing, Yandex, or Apertium backends.", "long_description": "Translate Shell is a command-line translator that wraps public Google, Bing, Yandex, and Apertium translation backends behind one `trans` command. It can translate inline text, stdin, files, and simple web pages, with extra modes for language identification, dictionaries, and speech output.\n\n## What It Enables\n- Translate ad hoc text, piped stdin, or input files into one or more target languages and write the result to stdout or a file.\n- Detect source languages, inspect supported language codes, and pull dictionary-style explanations or alternative translations when you need more than a single translated phrase.\n- Open translated web pages in a browser or play and download speech audio for translated text when a workflow needs quick localization or pronunciation help.\n\n## Agent Fit\n- `-brief`, stdin, stdout, `-input`, and `-output` make one-shot translation easy to drop into shell pipelines or small automation steps.\n- Most output is formatted for humans, and `-dump` only exposes raw upstream responses rather than a stable JSON contract owned by the tool.\n- Useful when an agent needs lightweight multilingual text transformation, but less dependable for unattended workflows because it relies on public translation endpoints and optional local helpers for audio, browser, or bidi support.\n\n## Caveats\n- Requires GNU Awk plus `bash` or `zsh`; audio, paging, bidi, and readline features need extra local programs.\n- Backend availability and raw response formats depend on external translation services outside the tool's control.", "category": "utilities", "install": "wget git.io\/trans && chmod +x .\/trans", "github": "https:\/\/github.com\/soimort\/translate-shell", "website": "https:\/\/www.soimort.org\/translate-shell\/", "source_url": null, "stars": 7413, "language": "Awk", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "ffsend", "name": "ffsend", "description": "Encrypted file-sharing CLI for uploading, downloading, and managing expiring shares on Send-compatible hosts.", "long_description": "ffsend is a Send-compatible file-sharing CLI that encrypts files client-side before uploading them to a public or self-hosted host. It covers the full share lifecycle from upload and download to metadata checks, password changes, and deletion.\n\n## What It Enables\n- Upload files, directories, or stdin as encrypted shares with optional passwords, expiry times, download limits, archive handling, and custom host selection.\n- Download shared files or archives, check whether a share still exists, and inspect metadata such as name, size, password requirement, download count, and remaining TTL.\n- Change a share's password or download limit and delete it later using the owner token or local history.\n\n## Agent Fit\n- `--no-interact`, `--yes`, `--force`, env var overrides, and `upload --quiet` make scripted handoff flows workable when a job just needs to emit a share URL.\n- There is no JSON mode, and most follow-up commands print tables or plain text, so parsing results is brittle compared with stronger automation-first CLIs.\n- Best fit is ephemeral file handoff between systems, CI jobs, or agents; it is less useful when you need a broader storage or collaboration surface.\n\n## Caveats\n- Value depends on a reachable Send-compatible service; the default public host is community-run, and the project says it is not affiliated with Mozilla or Firefox.\n- Some actions prompt by default, and optional URL shortening deliberately weakens the normal secret-in-link security model.", "category": "utilities", "install": "brew install ffsend", "github": "https:\/\/github.com\/timvisee\/ffsend", "website": "https:\/\/timvisee.com\/projects\/ffsend", "source_url": null, "stars": 7317, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "newman", "name": "Newman", "description": "Postman collection runner CLI for scripted API tests, smoke checks, and CI automation.", "long_description": "Newman is Postman's CLI for running Postman Collections outside the Postman app. It is built for repeatable collection execution in local scripts, CI jobs, and other shell-driven test workflows.\n\n## What It Enables\n- Run exported Postman collections or collection URLs with environments, globals, iteration data, folder selection, timeouts, SSL options, and file uploads.\n- Gate smoke tests or CI checks on collection failures, request errors, and script assertions, then export the final environment, globals, collection, or cookie jar after the run.\n- Produce run artifacts through built-in CLI, JSON, and JUnit reporters or custom reporters for downstream dashboards, alerts, or archival.\n\n## Agent Fit\n- `newman run` is stable and non-interactive once inputs are explicit, and its exit-code behavior makes follow-up shell automation straightforward.\n- Machine-readable output is real but file-oriented: the built-in JSON reporter writes a run summary artifact instead of emitting a generic `--json` stdout stream.\n- Best fit when API tests already live as Postman collections and an agent needs to parameterize, execute, and verify those runs from the shell.\n\n## Caveats\n- It depends on existing Postman collection artifacts or Postman API URLs, so it is less useful for ad hoc request authoring than raw HTTP CLIs.\n- Postman's newer Postman CLI covers some newer product surfaces, while Newman stays focused on open-source collection execution and reporter-driven test runs.", "category": "testing", "install": "npm install -g newman", "github": "https:\/\/github.com\/postmanlabs\/newman", "website": "https:\/\/learning.postman.com\/docs\/collections\/using-newman-cli\/command-line-integration-with-newman\/", "source_url": "https:\/\/www.postman.com", "stars": 7191, "language": "JavaScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Postman" }, { "slug": "fkill", "name": "fkill", "description": "Cross-platform process killer for terminating local processes by PID, name, or port.", "long_description": "fkill is a cross-platform process killer for terminating local processes by PID, name, or port, with an interactive picker when you run it without arguments. It is built for quick cleanup of hung apps and port conflicts rather than broad system inspection.\n\n## What It Enables\n- Kill local processes directly by PID, executable name, or `:port`, which is useful for clearing stuck apps or freeing a development port.\n- Fall back to an interactive fuzzy picker that lists running processes, ports, CPU, and memory when you know the workload but not the exact PID.\n- Use the same command across macOS, Linux, and Windows instead of juggling `kill`, `pkill`, `taskkill`, and separate port-lookup steps.\n\n## Agent Fit\n- Non-interactive arguments make it usable in repair loops or cleanup scripts, especially for killing a process that is holding a port open.\n- There is no JSON output or listing subcommand, so agents usually need other tools to inspect processes and use `fkill` only for the terminate step.\n- Default behavior can become interactive when no target is passed or a graceful kill fails, so unattended use is safest with exact inputs and explicit flags.\n\n## Caveats\n- It is a local process-control helper, not a full inspection tool; verification still belongs to `ps`, `lsof`, `tasklist`, or similar CLIs.\n- Without `--force`, failed terminations can hand off to interactive confirmation flows, which is awkward for headless automation.", "category": "system-monitoring", "install": "npm install -g fkill-cli", "github": "https:\/\/github.com\/sindresorhus\/fkill-cli", "website": null, "source_url": null, "stars": 6983, "language": "JavaScript", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "tfsec", "name": "tfsec", "description": "Terraform security scanning CLI for finding infrastructure misconfigurations in code and modules before apply.", "long_description": "tfsec is a static analysis CLI for Terraform that scans configuration files and modules for security misconfigurations before `plan` or `apply`. It is built for local and CI use, with built-in provider checks plus support for custom checks and Rego policies.\n\n## What It Enables\n- Scan Terraform repos and modules for risky network exposure, missing encryption, weak IAM settings, secrets exposure, and other provider-specific misconfigurations before infrastructure changes ship.\n- Gate pull requests or CI runs with severity thresholds, rule filters, ignore controls, tfvars inputs, and optional config or custom policy files.\n- Export findings as JSON, SARIF, JUnit, Checkstyle, CSV, Markdown, or HTML for code scanning systems, dashboards, and follow-up automation.\n\n## Agent Fit\n- `--format json`, non-interactive flags, and documented exit behavior make it easy to run in inspect-then-fix loops or CI.\n- Flags for excludes, minimum severity, workspace-specific ignores, tfvars, and module download control let an agent rerun targeted scans deterministically.\n- It is a read-only analysis primitive, so it fits safe review workflows well, but remediation still requires separate edits and some scans may need network access for remote modules.\n\n## Caveats\n- Aqua's own docs now encourage migration to `trivy config`, so tfsec remains useful but is no longer the forward-looking flagship in this product line.\n- Remote module fetching and custom policy inputs can change scan behavior; unattended runs may need `--no-module-downloads` or pinned config.", "category": "security", "install": "brew install tfsec", "github": "https:\/\/github.com\/aquasecurity\/tfsec", "website": "https:\/\/aquasecurity.github.io\/tfsec\/latest\/", "source_url": "https:\/\/aquasecurity.github.io\/trivy\/", "stars": 6964, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Aqua Security" }, { "slug": "sd", "name": "sd", "description": "Find-and-replace CLI for regex or literal text rewrites in stdin streams and files.", "long_description": "sd is a focused find-and-replace CLI for regex or literal text substitutions in stdin streams and files. It is a local text-transformation primitive for refactors, content cleanup, and scripted rewrites.\n\n## What It Enables\n- Rewrite matching text in stdin pipelines or files with regex captures or fixed-string replacements.\n- Preview replacements before writing, or apply them in place across many files when paired with tools like `fd` or `xargs`.\n- Handle line-oriented streaming by default, or switch to whole-input mode for multiline patterns and newline replacements.\n\n## Agent Fit\n- stdin and file inputs, stable flags, and in-place editing make it easy to drop into shell loops for local refactors.\n- Text output and exit behavior are predictable, but there is no JSON mode and `--preview` is explicitly a human-readable format that may change.\n- Best for local code, config, or content rewrites inside larger workflows rather than service or API operations.\n\n## Caveats\n- Files are modified in place by default unless you use `--preview`, so automated runs should stage changes or rely on version control.\n- Multiline work needs `--across`, which reads whole inputs, uses more memory, and disables streaming.", "category": "file-management", "install": "cargo install sd", "github": "https:\/\/github.com\/chmln\/sd", "website": null, "source_url": null, "stars": 6958, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "watchexec", "name": "watchexec", "description": "File-watching CLI for rerunning commands or emitting change events when watched files change.", "long_description": "watchexec watches directories for filesystem changes and then reruns a command, restarts a long-lived process, or emits structured change events. It is a local development and automation primitive for keeping builds, tests, servers, or sync jobs aligned with source edits.\n\n## What It Enables\n- Re-run tests, builds, linters, or sync commands whenever matching files change across a project tree.\n- Restart long-lived processes such as dev servers with debounce, signal, and process-group controls instead of leaving stale processes running.\n- Emit structured filesystem events to stdout, stdin, or a temp file so another program can react to changed paths directly.\n\n## Agent Fit\n- Watch scope, ignore rules, extension filters, debounce, restart, and shell controls make unattended runs predictable in scripts or agent loops.\n- `--only-emit-events` and `--emit-events-to=json-stdio|json-file` provide real machine-readable event data, but command lifecycle messages and child output remain mostly terminal text.\n- Best used as shell glue around another build, test, sync, or server command rather than as a standalone service-management interface.\n\n## Caveats\n- It is a long-running watcher, so agents need to manage process lifecycle, timeouts, and cleanup explicitly.\n- Default behavior runs the command once at startup and usually wraps it in a shell, which may need `--postpone` or `--shell=none` for stricter automation.", "category": "dev-tools", "install": "cargo install --locked watchexec-cli", "github": "https:\/\/github.com\/watchexec\/watchexec", "website": "https:\/\/watchexec.github.io\/docs\/#watchexec", "source_url": null, "stars": 6817, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "bombardier", "name": "Bombardier", "description": "HTTP benchmarking CLI for load testing APIs and web services and measuring latency, throughput, and status codes.", "long_description": "Bombardier is an HTTP benchmarking CLI for load testing APIs and web services from the terminal. It sends concurrent requests against a target URL and summarizes latency, request rates, throughput, HTTP codes, and errors.\n\n## What It Enables\n- Drive concurrent HTTP load against an endpoint for a fixed request count, test duration, or rate limit to check how an API or service behaves under pressure.\n- Benchmark realistic requests with custom methods, headers, bodies, streamed bodies, TLS client certificates, and selectable `fasthttp`, HTTP\/1.x, or HTTP\/2 clients.\n- Capture summary metrics in plain text, JSON, or a custom template for CI gates, regression checks, and side-by-side performance comparisons.\n\n## Agent Fit\n- Flags are non-interactive and script-friendly, so agents can drop it into deploy verification or benchmark loops without extra prompting.\n- Machine-readable output is real but opt-in: `-o json` plus result-only printing yields parseable metrics for throughput, latency, status codes, and aggregated errors.\n- Best for inspect-and-verify performance workflows; it generates load and reports outcomes, but agents need other tools to trace why a service slowed down or failed.\n\n## Caveats\n- Default output mixes intro and progress text with results, so automation should restrict printing when JSON is needed.\n- The README documents a `fasthttp` limitation around setting the `Host` header correctly; use `--http1` or `--http2` when that matters.", "category": "testing", "install": "go install github.com\/codesenberg\/bombardier@latest", "github": "https:\/\/github.com\/codesenberg\/bombardier", "website": null, "source_url": "https:\/\/github.com\/codesenberg\/bombardier", "stars": 6749, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "gopass", "name": "gopass", "description": "Encrypted password-store CLI for managing secrets, recipients, OTP data, and git-backed shared stores.", "long_description": "gopass is a command-line password and secret manager built around encrypted files, usually with GPG or age for crypto and git-backed stores for sharing. It is aimed at local or team-owned secret stores rather than a hosted vault API.\n\n## What It Enables\n- Initialize or clone encrypted password stores, organize them into mounted sub-stores, and sync shared stores through git remotes.\n- Read, insert, edit, move, grep, and pipe secrets or binary data from the shell, including script-oriented `show --password`, `otp --password`, and `cat` workflows.\n- Manage store recipients and OTP data so teams can share selected stores and generate TOTP codes from stored secrets.\n\n## Agent Fit\n- Commands are mostly regular subcommands with stdin\/stdout behavior, and several docs explicitly call out script-oriented flags such as `show --password`, `otp --password`, and `cat`.\n- The main CLI does not expose `--json` or similar structured output, so agents have to parse plain text and secret bodies carefully.\n- Best when a skill standardizes store layout, mount names, recipient operations, and key setup; first-run bootstrap, editor flows, clipboard actions, and key prompts are still human-heavy.\n\n## Caveats\n- Useful automation still depends on local crypto setup such as GPG or age keys, and typical shared-store workflows also assume git is configured.\n- Removing a recipient does not revoke access to secrets they already had; the docs warn affected secrets should be changed after recipient removal.", "category": "security", "install": "brew install gopass", "github": "https:\/\/github.com\/gopasspw\/gopass", "website": "https:\/\/www.gopass.pw\/", "source_url": null, "stars": 6737, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "sam", "name": "AWS SAM CLI", "description": "Official AWS CLI for scaffolding, building, testing, syncing, and deploying serverless applications with SAM templates.", "long_description": "AWS SAM CLI is AWS's command line for developing and operating serverless applications defined with SAM templates and related AWS infrastructure. It covers the common loop from project scaffolding and local emulation through deployment, cloud sync, and post-deploy inspection.\n\n## What It Enables\n- Scaffold serverless apps, validate templates, build artifacts, and run Lambda functions or local HTTP APIs before touching AWS.\n- Package and deploy SAM or CloudFormation stacks, sync code changes to development stacks, and bootstrap pipeline-oriented workflows from the shell.\n- Inspect stack resources, endpoints, and outputs, tail CloudWatch logs and X-Ray traces, and invoke deployed resources or durable executions for follow-up verification.\n\n## Agent Fit\n- The command surface spans create, change, and verify steps, so one tool can handle most of a serverless app's lifecycle instead of bouncing between raw AWS APIs and local glue scripts.\n- Structured output is real but uneven: several observability, list, and remote execution paths support JSON, while build, deploy, and sync flows mostly stream human-oriented progress.\n- Best fit when a skill already knows the template path, stack names, region, and whether guided flows should be replaced with explicit flags or config files.\n\n## Caveats\n- Useful workflows usually need AWS credentials, a serverless template, and for local emulation a working Docker setup.\n- Some commands default to interactive guidance or development-only behavior such as `sam deploy --guided` and `sam sync --watch`, so unattended runs should pin flags and target development stacks deliberately.", "category": "cloud", "install": null, "github": "https:\/\/github.com\/aws\/aws-sam-cli", "website": "https:\/\/docs.aws.amazon.com\/serverless-application-model\/latest\/developerguide\/using-sam-cli.html", "source_url": "https:\/\/aws.amazon.com\/serverless\/sam\/", "stars": 6700, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "AWS" }, { "slug": "trippy", "name": "trippy", "description": "Network path tracing CLI with a fullscreen TUI plus JSON, CSV, table, flow, and DOT reports.", "long_description": "trippy is a network path tracing tool that combines traceroute-style hop discovery with ping-like latency statistics. Its `trip` command can run as a fullscreen terminal UI or as a fixed-cycle report generator for saved diagnostics.\n\n## What It Enables\n- Trace routes to one or more targets over ICMP, UDP, or TCP with control over ports, TTL ranges, address family, and ECMP strategy.\n- Inspect hop-by-hop latency, loss, jitter, DNS names, ASN data, GeoIP data, NAT detection, and per-flow path differences while debugging network problems.\n- Emit JSON, CSV, table, flow, or Graphviz DOT reports after a set number of rounds for scripted diagnostics, CI artifacts, or follow-up analysis.\n\n## Agent Fit\n- Non-interactive flags and `--mode json` make it usable in shell loops when an agent needs structured path and latency data.\n- The default experience is a fullscreen TUI, and many of the richest views like charts, maps, and hop navigation are aimed at human inspection rather than unattended automation.\n- Best fit for network diagnosis on machines an agent already controls, especially when paired with follow-up shell tools that consume the JSON report.\n\n## Caveats\n- Raw-socket tracing usually needs elevated privileges, and documented unprivileged mode support is limited to supported platforms.\n- Some enrichment features depend on optional local data files, such as MaxMind or IPinfo mmdb databases for GeoIP views.", "category": "networking", "install": "brew install trippy", "github": "https:\/\/github.com\/fujiapple852\/trippy", "website": "https:\/\/trippy.rs\/", "source_url": null, "stars": 6678, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "dog", "name": "dog", "description": "DNS lookup CLI for querying records over UDP, TCP, DNS-over-TLS, or DNS-over-HTTPS with optional JSON output.", "long_description": "dog is a DNS query CLI for checking how domains resolve and what records a resolver returns. It supports standard DNS over UDP or TCP plus DNS-over-TLS and DNS-over-HTTPS when you need to test a specific resolver path.\n\n## What It Enables\n- Query A, AAAA, MX, TXT, CNAME, SOA, SRV, PTR, TLSA, and other record types against the system resolver or an explicit nameserver.\n- Verify how a domain resolves over UDP, TCP, DNS-over-TLS, or DNS-over-HTTPS when debugging resolver behavior, privacy transports, or split DNS.\n- Capture structured DNS responses, including answers, authorities, additionals, and optional timing, for scripts or follow-up checks.\n\n## Agent Fit\n- `--json` output and non-interactive flags make it easy to wrap in shell scripts, CI checks, or agent loops that need to inspect DNS state.\n- Commands are inspect-only and predictable, but the tool cannot create or edit records, so it usually pairs with a provider-specific CLI for remediation.\n- Exit behavior is mostly stable, but missing records can still exit 0 outside `--short`, so agents should parse the response body instead of treating success as proof that a record exists.\n\n## Caveats\n- This is a DNS inspection tool only; any change workflow still depends on your DNS provider or infrastructure CLI.\n- DNS-over-HTTPS requires a full resolver URL rather than a bare nameserver address.", "category": "networking", "install": "brew install dog", "github": "https:\/\/github.com\/ogham\/dog", "website": "https:\/\/dns.lookup.dog\/", "source_url": null, "stars": 6622, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "csvkit", "name": "csvkit", "description": "Command-line suite for converting tabular files to CSV, transforming CSV data, and querying it with SQL.", "long_description": "csvkit is a collection of small commands for moving tabular data into CSV, reshaping it with Unix-style filters, and bridging CSVs to JSON or SQL. It is most useful when you need quick inspection, cleanup, joins, or ad hoc queries without opening a spreadsheet or writing a custom script.\n\n## What It Enables\n- Convert Excel, JSON, ndjson, DBF, GeoJSON, and fixed-width sources into CSV for shell pipelines.\n- Inspect, filter, sort, join, stack, clean, and reformat CSV files with single-purpose commands like `csvcut`, `csvgrep`, `csvjoin`, and `csvsort`.\n- Generate summary stats, emit JSON or GeoJSON, and run ad hoc SQL queries or move CSV data into databases with `csvstat`, `csvjson`, `csvsql`, and `sql2csv`.\n\n## Agent Fit\n- Most commands are non-interactive, accept stdin or file inputs, and write predictable stdout, so they compose cleanly in shell loops and scripts.\n- Structured output is present but uneven across the suite: `csvjson` emits JSON, GeoJSON, or NDJSON, and `csvstat --json` returns machine-readable stats, while many other commands stay CSV or text-first.\n- Best fit for small to medium tabular workflows, preprocessing steps, and inspect or transform loops before handing larger analysis to SQL engines or faster CSV tooling.\n\n## Caveats\n- CSV dialect sniffing and type inference are convenient but can misread edge cases; the docs recommend `--snifflimit 0` and `--no-inference` when you need deterministic parsing.\n- The docs explicitly warn that csvkit reaches its limits on larger files, and `csvsql --query` works by loading data into an in-memory SQLite database.", "category": "data-processing", "install": "pip install csvkit", "github": "https:\/\/github.com\/wireservice\/csvkit", "website": "https:\/\/csvkit.readthedocs.io\/en\/latest\/", "source_url": null, "stars": 6354, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "k3d", "name": "k3d", "description": "CLI for creating and managing local k3s Kubernetes clusters in Docker, including kubeconfig, image import, and registry workflows.", "long_description": "k3d is a CLI for running k3s Kubernetes clusters as Docker containers on one machine. It is mainly a fast local control surface for spinning clusters up and down, wiring access, and shaping repeatable dev or test environments.\n\n## What It Enables\n- Create single-node or multi-node local k3s clusters, start or stop them, and delete them when a test or debugging run is done.\n- Merge or write kubeconfig for those clusters, create or attach local registries, and import container images without pushing to a remote registry first.\n- Define cluster shape in YAML config files, validate or migrate that config, and reuse the same setup across local development, CI, or agent-run test loops.\n\n## Agent Fit\n- Well suited to local inspect-change-verify loops because cluster lifecycle commands are explicit, non-TUI, and easy to script around Docker plus `kubectl`.\n- Structured output exists, but only on part of the surface: `version` supports JSON and `cluster`, `node`, and `registry list` support `-o json|yaml`, while most create or mutate commands log human-oriented progress.\n- Best when an agent needs disposable Kubernetes environments on a machine it already controls, not when it needs full cluster introspection without follow-up tools.\n\n## Caveats\n- Requires a working Docker runtime, and practical use usually also depends on `kubectl` plus whatever manifests or tooling you run inside the cluster.\n- k3d is community-run rather than an official Rancher or SUSE CLI, and its config format is still documented as alpha and subject to change.", "category": "containers", "install": "curl -s https:\/\/raw.githubusercontent.com\/k3d-io\/k3d\/main\/install.sh | bash", "github": "https:\/\/github.com\/k3d-io\/k3d", "website": "https:\/\/k3d.io", "source_url": "https:\/\/k3d.io", "stars": 6294, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "pastel", "name": "pastel", "description": "Color manipulation CLI for converting formats, generating palettes, and styling terminal output.", "long_description": "pastel is a color utility CLI for converting color formats, generating palettes, and previewing or styling colors in the terminal. It is aimed at shell workflows where color values need to be inspected, transformed, or embedded in terminal output.\n\n## What It Enables\n- Convert colors between named colors, hex, RGB, HSL, Lab, OkLab or OkLCh, CMYK, ANSI, and channel-specific numeric values.\n- Generate random, gradient, or visually distinct palettes, then sort, mix, lighten, darken, rotate, or otherwise transform them in shell pipelines.\n- Pick a screen color, choose a readable foreground with `textcolor`, and print ANSI-colored labels or status text from scripts.\n\n## Agent Fit\n- Most subcommands are non-interactive, accept values from args or stdin, and emit one result per line, which works well in inspect-transform pipelines.\n- Output is plain text or ANSI-colored text rather than JSON, so agents need command-specific parsing and should avoid colorized views when exact values matter.\n- Best for local design, theming, docs, or terminal UX automation; it is less useful for workflows centered on remote services or structured APIs.\n\n## Caveats\n- `pick` depends on an external color picker or the macOS built-in picker, so that path introduces a human step and desktop dependency.\n- Some commands render richer previews only when stdout is a TTY; automation should prefer explicit formatting commands like `format` for stable output.", "category": "utilities", "install": "brew install pastel", "github": "https:\/\/github.com\/sharkdp\/pastel", "website": null, "source_url": null, "stars": 6279, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "sanity", "name": "Sanity CLI", "description": "Official Sanity CLI for Studio setup, datasets, documents, schema tooling, deployments, and content platform operations.", "long_description": "Sanity CLI is the official command surface for creating, developing, and operating Sanity Studio projects and the underlying content platform. It covers local studio workflows, content and dataset operations, schema and API tooling, and deployment tasks.\n\n## What It Enables\n- Initialize studios or apps, run local dev and deploy flows, and manage project settings, datasets, CORS, tokens, users, and project creation from the shell.\n- Query, fetch, create, delete, import, export, validate, and migrate content and datasets without going through the Studio UI.\n- Extract schemas, generate types, deploy GraphQL APIs, inspect OpenAPI specs, and operate newer platform surfaces such as functions and blueprints.\n\n## Agent Fit\n- Several high-value commands return structured JSON, including document queries and gets, token and project flows, OpenAPI output, function logs, and blueprint diagnostics.\n- The CLI exposes real inspect\/change\/verify loops across content, schema, datasets, and deployments, so it fits scripted maintenance, migrations, and CI workflows well.\n- It can also configure Sanity MCP server entries for supported AI editors, though the direct shell commands are the more important automation surface here.\n\n## Caveats\n- A lot of the value depends on an existing `sanity.cli.ts` project context and Sanity credentials; `sanity login` opens a browser by default.\n- JSON support is command-specific rather than universal, and init or deploy flows still lean on prompts unless you pass unattended flags.", "category": "http-apis", "install": "npm install --global sanity@latest", "github": "https:\/\/github.com\/sanity-io\/sanity", "website": "https:\/\/www.sanity.io\/docs\/cli", "source_url": "https:\/\/www.sanity.io", "stars": 6023, "language": "TypeScript", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Sanity" }, { "slug": "tmate", "name": "tmate", "description": "Terminal sharing CLI for launching shareable tmux sessions over SSH for pair debugging and remote support.", "long_description": "tmate is a fork of tmux that turns a local terminal session into a shareable remote session reachable through tmate servers. It is mainly for pair debugging, remote support, and getting a live shell in front of someone else quickly without exposing SSH directly.\n\n## What It Enables\n- Start a tmux-backed session and hand out generated SSH or web join details so another person can enter the same shell.\n- Run headless shared sessions for remote support, ephemeral admin access, or debugging on machines behind NAT.\n- Restrict access with authorized keys, create separate read-only sessions, and script around session readiness before surfacing connection details.\n\n## Agent Fit\n- Useful for agents mainly as a collaboration handoff: start the session, wait for `tmate-ready`, surface the join command, then let a human inspect or intervene.\n- There is no JSON output, and most of the product value lives in the interactive terminal session rather than a broad inspectable CLI API.\n- Control mode and stable flags make it scriptable enough for wrappers and CI escape hatches, but it is not a rich machine-facing operations CLI.\n\n## Caveats\n- Shared access depends on tmate backend servers by default, or on running your own server if you need full control.\n- Named sessions on `tmate.io` require an API key.", "category": "shell-utilities", "install": "brew install tmate", "github": "https:\/\/github.com\/tmate-io\/tmate", "website": "https:\/\/tmate.io\/", "source_url": "https:\/\/github.com\/tmate-io\/tmate", "stars": 6002, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": true, "source_type": "github", "vendor_name": "tmate" }, { "slug": "procs", "name": "procs", "description": "Process inspection CLI for searching, sorting, and exporting local process data with JSON output.", "long_description": "procs is a replacement for `ps` that makes local process inspection easier with search, richer columns, and optional tree or watch views. It focuses on understanding what is running on a machine, including ports, throughput, and container context when the OS exposes them.\n\n## What It Enables\n- Search running processes by PID, user, command, or other configured columns, then sort or filter the results for follow-up shell actions.\n- Inspect richer process state than stock `ps`, including CPU and memory usage, elapsed time, read or write throughput, bound TCP or UDP ports, and Docker container names when available.\n- Export process rows as JSON or switch to tree and watch views to trace parent-child relationships and live changes during debugging.\n\n## Agent Fit\n- `--json`, stable flags, and non-interactive search or sort modes make it easy to wrap in scripts that need to find processes before killing, tracing, or querying them with other tools.\n- It is a local, read-only inspection surface rather than a broader service-management CLI, so the value is strongest in inspect and verify loops.\n- Watch mode and pager behavior are more human-oriented, and some high-value fields depend on platform support, elevated privileges, or Docker socket access.\n\n## Caveats\n- Some columns are platform-specific, and macOS or Linux permissions can hide other users' processes or I\/O and port data unless run with elevated privileges.\n- Docker names require access to the Docker socket, and watch mode is an interactive loop rather than a headless monitoring API.", "category": "system-monitoring", "install": "brew install procs", "github": "https:\/\/github.com\/dalance\/procs", "website": null, "source_url": null, "stars": 5951, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "gog", "name": "gog", "description": "Unofficial Google Workspace CLI for Gmail, Calendar, Drive, Docs, Sheets, Chat, Contacts, Tasks, and admin workflows.", "long_description": "gog is an unofficial Google Workspace CLI that brings Gmail, Calendar, Drive, Docs, Sheets, Chat, Contacts, Tasks, Classroom, and related Google APIs into one shell tool. It is aimed at direct terminal automation across multiple Google accounts, with both read and write commands.\n\n## What It Enables\n- Read, search, and send Gmail; inspect attachments and threads; manage labels, drafts, forwarding, filters, and mailbox watches.\n- List, search, upload, download, share, and export Drive files, then create or edit Docs, Sheets, Slides, Forms, and Apps Script resources from the shell.\n- Manage calendars, tasks, contacts, chat spaces and messages, classroom objects, groups, and some Workspace admin or service-account flows without leaving the terminal.\n\n## Agent Fit\n- Global `--json` and `--plain` output modes keep stdout parseable, while prompts and progress stay on stderr.\n- Global `--no-input`, `--force`, and `--enable-commands` flags, plus `schema` and `agent exit-codes`, make it easier to wrap in agent loops or constrained sandboxes.\n- The first auth flow is the main friction point: you usually need Google OAuth credentials and browser consent before unattended automation becomes smooth.\n\n## Caveats\n- This is not an official Google CLI, so coverage and behavior depend on the open source project rather than vendor support.\n- Some commands are Workspace-only or require service-account delegation, and scopes must be granted explicitly.", "category": "google-workspace", "install": "brew install gogcli", "github": "https:\/\/github.com\/steipete\/gogcli", "website": "https:\/\/gogcli.sh\/", "source_url": null, "stars": 5887, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "google", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "bats", "name": "bats", "description": "Bash test runner for `.bats` files that verify shell scripts and other Unix commands.", "long_description": "Bats is a Bash test runner for `.bats` files that wrap shell commands in a TAP-oriented test harness. It is mainly a verification tool for Bash scripts and other Unix command-line behavior.\n\n## What It Enables\n- Run repeatable shell test suites that assert command exit codes, stdout and stderr, and line-by-line output.\n- Target only the tests you need with file or directory runs, recursive discovery, regex filters, tag filters, or reruns based on last failure status.\n- Feed results into CI or agent verify loops with TAP or TAP13 output and optional JUnit report files.\n\n## Agent Fit\n- Exit codes are simple and dependable: `0` when every test passes and `1` when any test fails.\n- Non-interactive flags and machine-readable TAP or JUnit outputs work well in scripts, but there is no native JSON output.\n- Best fit is shell-heavy projects where an agent needs to verify behavior after edits rather than control external services directly.\n\n## Caveats\n- You only get value once meaningful `.bats` tests exist; the CLI is a runner, not a test generator.\n- Parallel execution requires GNU `parallel` or a compatible replacement such as `rush`.", "category": "testing", "install": "brew install bats-core", "github": "https:\/\/github.com\/bats-core\/bats-core", "website": "https:\/\/bats-core.readthedocs.io\/en\/stable\/", "source_url": null, "stars": 5867, "language": "Shell", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "cosign", "name": "cosign", "description": "Official Sigstore CLI for signing, verifying, and attesting container images, blobs, and other software artifacts.", "long_description": "Cosign is Sigstore's CLI for signing, verifying, and attaching provenance data to container images, blobs, and other OCI-addressed artifacts. It is a supply-chain integrity tool: publish signatures or attestations, then verify them against keys, certificates, identities, transparency logs, and trusted roots.\n\n## What It Enables\n- Sign container images or blobs with keyless OIDC, local keys, hardware tokens, or cloud KMS, and attach the resulting signatures or bundles to OCI registries.\n- Verify image signatures, blob signatures, and attestations against expected keys, certificate identities, OIDC issuers, transparency logs, or offline trusted-root bundles.\n- Inspect and retrieve supply-chain metadata around an image, including signatures, attestations, SBOM attachments, and other related OCI artifacts.\n\n## Agent Fit\n- Important read paths are machine-friendly: `verify` and `verify-attestation` default to JSON output, and `version --json` is explicitly supported.\n- The subcommands map well to inspect and verify loops in CI or agent workflows because signing, verification, download, and tree inspection are direct shell commands with stdout-first conventions.\n- Automation is strongest when auth and trust inputs are already wired up; default keyless signing can still prompt for consent or browser-based OIDC login, and safe verification depends on passing explicit identity, issuer, key, or trusted-root expectations.\n\n## Caveats\n- Default keyless signing can open an interactive OIDC flow unless you provide non-interactive credentials such as `--identity-token` and suppress confirmation prompts.\n- Verification is security-sensitive rather than plug-and-play: pin image digests and expected signer identity or key material instead of treating a bare success as sufficient.", "category": "security", "install": "go install github.com\/sigstore\/cosign\/v3\/cmd\/cosign@latest", "github": "https:\/\/github.com\/sigstore\/cosign", "website": "https:\/\/docs.sigstore.dev\/cosign\/", "source_url": "https:\/\/github.com\/sigstore\/cosign", "stars": 5708, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Sigstore" }, { "slug": "clipboard", "name": "Clipboard", "description": "Terminal clipboard manager for copying, pasting, searching, and syncing text, files, and raw data across named and system clipboards.", "long_description": "Clipboard is a terminal-first clipboard manager built around the `cb` command. It stores text, files, directories, and raw data in named clipboards with history, then syncs the default clipboard with GUI and remote terminal clipboards when the environment supports it.\n\n## What It Enables\n- Copy or cut text, files, directories, and raw data into reusable named clipboards instead of relying on a single ephemeral system clipboard.\n- Search clipboard contents, inspect clipboard metadata and history, attach notes, and load or swap saved clipboard contents between clipboard slots.\n- Bridge shell workflows with desktop and remote clipboard systems, including GUI clipboard sync and OSC 52 clipboard writes from terminal sessions.\n\n## Agent Fit\n- The command surface is broad but still shell-native, so agents can script local handoff workflows that need more than ordinary pipes or temp files.\n- Machine-readable output exists for `info`, `status`, `history`, and `search`, but it is triggered by non-TTY stdout rather than an explicit `--json` flag and the rest of the CLI is mostly human-first text.\n- Best for agents operating on a developer desktop or remote terminal where clipboard handoff matters; it is less compelling on headless hosts where files and pipes already cover most data movement.\n\n## Caveats\n- Several write flows can prompt on file replacement during paste, so unattended runs need `CI` or `--no-confirmation` where appropriate.\n- The `share` action is listed but currently unimplemented in source, and clipboard scripts are not supported on Windows.", "category": "utilities", "install": "curl -sSL https:\/\/github.com\/Slackadays\/Clipboard\/raw\/main\/install.sh | sh", "github": "https:\/\/github.com\/Slackadays\/Clipboard", "website": "https:\/\/getclipboard.app\/", "source_url": null, "stars": 5699, "language": "C++", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "dua", "name": "dua", "description": "Disk usage CLI for scanning directories quickly and cleaning up space from an interactive terminal UI.", "long_description": "dua is a local disk-usage analyzer that scans filesystems in parallel and reports which paths consume space. It pairs a fast aggregate mode for terminal output with an interactive mode for browsing and deleting files or directories.\n\n## What It Enables\n- Scan one or more paths to see which directories or files are using disk space, with options for byte units, apparent size, hard-link counting, ignore lists, and filesystem boundaries.\n- Run quick aggregates over the current directory or explicit paths to triage build caches, logs, downloads, and other local storage hotspots.\n- Open the interactive TUI to browse the tree, mark entries, and delete or trash unwanted files and directories.\n\n## Agent Fit\n- The aggregate path is non-interactive and works for local inspect-and-decide loops, with predictable flags and exit codes.\n- Automation is limited by human-readable output only; there is no `--json` or structured export mode for reliable downstream parsing.\n- Best for agent-assisted local cleanup when simple text output is enough to identify the next action or a human can take over in the TUI.\n\n## Caveats\n- Destructive actions live mainly in the interactive UI, which requires a connected terminal.\n- It only operates on the local filesystem visible to the current machine.", "category": "system-monitoring", "install": "brew install dua-cli", "github": "https:\/\/github.com\/Byron\/dua-cli", "website": null, "source_url": null, "stars": 5666, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "entr", "name": "entr", "description": "File watcher CLI that reruns commands or restarts a child process when watched files change.", "long_description": "entr watches a list of files from stdin and runs a command when one of them changes. It is a small local-development primitive for rebuild, test, query, or server-reload loops without polling.\n\n## What It Enables\n- Re-run tests, builds, linters, or database queries whenever a watched file changes.\n- Restart a long-lived process such as a dev server or worker with `-r`, so code changes trigger a clean reload.\n- Watch parent directories for added or removed files with `-d` and pass the first changed path into the command with `\/_`.\n\n## Agent Fit\n- Works well as shell glue around other CLIs because commands, flags, exit behavior, and stdin-driven file lists are simple and predictable.\n- `-n` gives a non-interactive mode and `-z` can return the child process status, but there is no JSON or other structured output to inspect.\n- Best for local edit-build-test or auto-reload loops where an agent wants the shell to stay reactive between file changes.\n\n## Caveats\n- It only watches the file list you pipe in; recursive discovery and glob refresh usually come from `find`, `ls`, or a surrounding shell loop.\n- Default mode opens a TTY for the child process, so unattended usage should generally opt into `-n` and use commands that behave well when restarted.", "category": "dev-tools", "install": ".\/configure && make test && make install", "github": "https:\/\/github.com\/eradman\/entr", "website": "https:\/\/eradman.com\/entrproject\/", "source_url": null, "stars": 5483, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "snyk", "name": "Snyk CLI", "description": "Official Snyk CLI for testing dependencies, code, containers, and IaC for vulnerabilities, policy issues, and ongoing monitoring.", "long_description": "Snyk CLI is Snyk's shell interface for testing software projects, container images, and infrastructure definitions against Snyk's vulnerability and policy data. It also snapshots projects for ongoing monitoring and exposes newer SBOM, AI-BOM, and AI red-team workflows when those products are enabled.\n\n## What It Enables\n- Test dependency manifests, source code, container images, and IaC files locally or in CI, then filter or export findings for gating and remediation.\n- Snapshot projects to Snyk with `monitor`, attach repo and project metadata, and keep receiving new-vulnerability alerts after the initial scan.\n- Generate SBOMs, detect unmanaged cloud resources with `iac describe`, and run newer AI-BOM or red-team scans for supported environments.\n\n## Agent Fit\n- Core scan commands are non-interactive and return distinct exit codes for clean results, findings, and failures, which fits CI and agent retry loops.\n- JSON and SARIF output are available across `test`, `code test`, `container test`, `iac test`, `monitor`, and `iac describe`, so follow-up parsing is straightforward.\n- The repo also ships first-party MCP-related support such as `mcp-scan`, but the main automation value is still direct CLI use against Snyk scans and reports.\n\n## Caveats\n- Most real workflows require Snyk authentication, internet access, and in some cases paid or experimental features rather than a fully local scan.\n- Open source and some ecosystem scans may invoke package managers or project builds, so the relevant tooling must already be installed and trusted.", "category": "security", "install": "brew tap snyk\/tap && brew install snyk", "github": "https:\/\/github.com\/snyk\/cli", "website": "https:\/\/docs.snyk.io\/developer-tools\/snyk-cli", "source_url": "https:\/\/snyk.io", "stars": 5443, "language": "TypeScript", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Snyk" }, { "slug": "gdu", "name": "gdu", "description": "Disk usage analyzer for finding large directories, browsing folder trees in a terminal UI, and exporting scans as JSON.", "long_description": "gdu is a local disk usage analyzer for scanning directory trees and surfacing where space is going. It defaults to a fullscreen terminal UI, but also supports non-interactive text output and JSON export for saved or scripted analysis.\n\n## What It Enables\n- Scan a directory tree or mounted disks to find large folders and files, with options for apparent size, item counts, top files, depth limits, and time-based filtering.\n- Browse results interactively, then delete items, empty directories, inspect file contents, or spawn a shell from the current location while cleaning up storage.\n- Export a full scan as JSON or save analysis in SQLite or Badger storage, then reopen those results later without rescanning the filesystem.\n\n## Agent Fit\n- Most of the product value sits in the fullscreen TUI, so unattended agent use is weaker than CLIs built around stable subcommands and structured stdout by default.\n- There is still a practical automation surface: non-interactive mode prints directory stats for scripts, and `-o` exports machine-readable scan snapshots for later parsing or review.\n- Best used as a local inspection primitive inside cleanup or incident workflows where an agent needs to locate storage hotspots before handing off or confirming destructive actions.\n\n## Caveats\n- It only inspects the local filesystem visible to the current machine, so remote storage or cloud volume workflows need other CLIs.\n- JSON support is snapshot export and import rather than a general `--json` mode on every command, and destructive actions are mainly exposed through the interactive UI.", "category": "file-management", "install": "brew install -f gdu", "github": "https:\/\/github.com\/dundee\/gdu", "website": null, "source_url": "https:\/\/github.com\/dundee\/gdu", "stars": 5382, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "vale", "name": "Vale", "description": "Prose linting CLI for docs, markup files, and code comments using configurable editorial style rules.", "long_description": "Vale is a prose linter for documentation, markup files, and supported code comments that applies configurable style, spelling, readability, and terminology rules from a local `.vale.ini` and styles tree. It is built for docs review, editor integration, and CI enforcement rather than terminal-first authoring.\n\n## What It Enables\n- Lint Markdown, AsciiDoc, reStructuredText, HTML, XML, Org, plain text, and supported code comments from files, directories, strings, or stdin.\n- Enforce house style, spelling, capitalization, terminology, and readability checks through local configs, vocabularies, and downloadable style packages.\n- Emit JSON or line-based findings plus config, directory, and file-metric data for CI gates, editor integrations, and follow-up edits.\n\n## Agent Fit\n- `--output=JSON`, stdin support, and tested `0`\/`1`\/`2` exit behavior make parse-edit-rerun loops straightforward.\n- Repo-local `.vale.ini` files and style packages fit skill-based workflows well: an agent can inspect the config, run `sync`, lint changed files, and verify documentation edits with the same rules used in CI.\n- Most value is in detection, not remediation; Vale usually reports issues for a human or agent to rewrite rather than fixing prose automatically.\n\n## Caveats\n- Useful results depend on a project config and styles or vocabulary; first-run setup may require checked-in rules or a `vale sync` step.\n- If teams rely on custom templates instead of JSON or line output, follow-up parsing becomes more workflow-specific.", "category": "dev-tools", "install": "brew install vale", "github": "https:\/\/github.com\/errata-ai\/vale", "website": "https:\/\/vale.sh", "source_url": "https:\/\/vale.sh", "stars": 5277, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "eksctl", "name": "eksctl", "description": "Official Amazon EKS CLI for creating clusters, managing nodegroups and addons, and updating access or networking settings on AWS.", "long_description": "eksctl is the official CLI for provisioning and operating Amazon EKS clusters, nodegroups, and cluster-adjacent features from the shell. It wraps EKS, CloudFormation, IAM, and related AWS APIs behind a config-file-friendly command surface.\n\n## What It Enables\n- Create, upgrade, and delete EKS clusters, managed or self-managed nodegroups, and kubeconfig state from flags or `ClusterConfig` files.\n- Manage EKS add-ons, access entries, IAM service accounts or OIDC wiring, and newer features like Auto Mode without stitching raw AWS API calls together.\n- Inspect clusters, add-ons, and CloudFormation stacks to verify state before or after changes.\n\n## Agent Fit\n- Config-file support, explicit flags, and plan mode plus `--approve` fit inspect-change-verify loops for EKS infrastructure work.\n- Structured output is real but partial: `get`, `info`, `version`, and some `utils` commands emit JSON or YAML, while many create or update flows still stream human-oriented progress logs.\n- Can also connect to MCP-based setups through the hidden `eksctl mcp` stdio server when that integration model is needed.\n\n## Caveats\n- You need AWS credentials and broad EKS, EC2, CloudFormation, IAM, and related permissions before most commands will work.\n- Mutating commands can be long-running and sometimes rely on follow-up tools like `kubectl` or manual CloudFormation cleanup when AWS-side resources block deletion.", "category": "containers", "install": "ARCH=$(uname -m); [ \"$ARCH\" = \"x86_64\" ] && ARCH=amd64; [ \"$ARCH\" = \"aarch64\" ] && ARCH=arm64; [ \"$ARCH\" = \"arm64\" ] && ARCH=arm64; PLATFORM=$(uname -s)_$ARCH && curl -sLO \"https:\/\/github.com\/eksctl-io\/eksctl\/releases\/latest\/download\/eksctl_${PLATFORM}.tar.gz\" && tar -xzf \"eksctl_${PLATFORM}.tar.gz\" -C \/tmp && sudo install -m 0755 \/tmp\/eksctl \/usr\/local\/bin", "github": "https:\/\/github.com\/eksctl-io\/eksctl", "website": "https:\/\/eksctl.io", "source_url": "https:\/\/eksctl.io", "stars": 5183, "language": "Go", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Amazon EKS" }, { "slug": "wp-cli", "name": "WP-CLI", "description": "Official WordPress command-line interface for core, plugins, themes, config, content, and multisite operations.", "long_description": "WP-CLI is the command-line interface for administering WordPress installations without using wp-admin. It covers core setup, plugins, themes, content, database tasks, multisite operations, and remote execution against targeted installs.\n\n## What It Enables\n- Install, update, activate, and inspect plugins or themes, configure core settings, and run common site-admin tasks from the shell instead of the browser.\n- Inspect and change WordPress data, including posts, options, transients, imports, exports, and database search-replace operations.\n- Target local or remote installs with `--path`, `--url`, `--ssh`, `--http`, or saved aliases so the same workflow can run against dev, staging, or production sites.\n\n## Agent Fit\n- The command surface is mostly flag-driven, and site-targeting flags plus aliases make inspect, mutate, and verify loops practical across multiple WordPress environments.\n- Many commands can emit structured output through `--format=json`, and the framework also exposes JSON command and parameter dumps that help agents discover what is available.\n- It works best as a generic WordPress action layer that skills can pin to the right site, user, and safety flags for a specific project.\n\n## Caveats\n- Structured output is command-specific, so some commands still return prose and need per-command parsing instead of a uniform JSON contract.\n- Most commands bootstrap WordPress itself, which can execute plugin or theme code; remote or fragile sites often need careful targeting and flags like `--skip-plugins`, `--skip-themes`, or `--context`.", "category": "http-apis", "install": "curl -O https:\/\/raw.githubusercontent.com\/wp-cli\/builds\/gh-pages\/phar\/wp-cli.phar && chmod +x wp-cli.phar && sudo mv wp-cli.phar \/usr\/local\/bin\/wp", "github": "https:\/\/github.com\/wp-cli\/wp-cli", "website": "https:\/\/wp-cli.org\/", "source_url": "https:\/\/wp-cli.org\/", "stars": 5030, "language": "PHP", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "WordPress" }, { "slug": "maven", "name": "Maven", "description": "Java build CLI for lifecycle phases, dependency resolution, plugin goals, and multi-module builds.", "long_description": "Maven is the standard CLI for building Java projects from a `pom.xml`, resolving dependencies, and running lifecycle phases or plugin goals. It covers compile, test, package, install, deploy, reporting, and site-generation workflows, especially in multi-module repositories.\n\n## What It Enables\n- Run standard Java build phases such as compile, test, package, verify, install, and deploy from the shell.\n- Resolve dependencies and plugins from Maven repositories, then build selected modules or resume failed reactor builds.\n- Invoke plugin goals for checks, code generation, documentation, site publishing, and release workflows defined by the project.\n\n## Agent Fit\n- Batch mode, project selection, resume flags, thread control, and log-file output make it workable in CI jobs and agent retry loops.\n- The command surface is stable, but output is mostly human-oriented build logs with no native JSON mode for structured parsing.\n- Best fit when an agent is operating inside an existing Maven repo where the `pom.xml` already encodes the workflow; less self-describing than service CLIs because plugins and profiles change behavior per project.\n\n## Caveats\n- Requires a compatible JDK, and private repositories or deploy targets often need credentials in `settings.xml` or related config.\n- What `mvn` does can vary widely by project because plugins, profiles, toolchains, and repository settings drive the actual build behavior.", "category": "package-managers", "install": "brew install maven", "github": "https:\/\/github.com\/apache\/maven", "website": "https:\/\/maven.apache.org", "source_url": "https:\/\/maven.apache.org", "stars": 4980, "language": "Java", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Apache Maven" }, { "slug": "s3cmd", "name": "s3cmd", "description": "S3-compatible object-storage CLI for buckets, uploads, syncs, ACLs, policies, and lifecycle automation.", "long_description": "s3cmd is a long-running community CLI for Amazon S3 and other S3-compatible object stores. It covers file transfer, bucket inspection, and bucket-level configuration from the shell.\n\n## What It Enables\n- Create buckets, list objects, upload or fetch files, restore Glacier objects, and sync local trees to or from S3-compatible storage.\n- Apply ACLs, versioning, ownership, public-access blocks, tags, policies, CORS, lifecycle rules, and notification configs without using a web console.\n- Manage static website settings, signed URLs, multipart uploads, and basic CloudFront distribution or invalidation tasks from scripts.\n\n## Agent Fit\n- Commands are non-interactive after credentials and endpoint settings are in place, with dry-run, retry, and partial-failure exit codes that work in scripted transfer loops.\n- The weak point is output shape: most commands print plain text, and some reads return prettified XML, so follow-up parsing is more brittle than JSON-first CLIs.\n- Best fit is backup, sync, and bucket-admin workflows where a skill can hide config details and wrap the text-oriented output.\n\n## Caveats\n- Initial setup commonly goes through `--configure`, which is interactive unless you manage `~\/.s3cfg`, environment variables, or flags yourself.\n- This is a community project rather than an official AWS CLI, and some features reflect older S3 or CloudFront workflows.", "category": "cloud", "install": "brew install s3cmd", "github": "https:\/\/github.com\/s3tools\/s3cmd", "website": "https:\/\/s3tools.org\/s3cmd", "source_url": null, "stars": 4868, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "summarize", "name": "summarize", "description": "Summarization CLI for URLs, local files, podcasts, and media, with JSON output and optional browser side-panel support through a local daemon.", "long_description": "summarize is a content-ingestion CLI that fetches URLs or local files, extracts readable text or transcripts, and turns them into summaries. It also powers a browser side panel through a local daemon, but the core tool is a flag-driven terminal workflow.\n\n## What It Enables\n- Turn web pages, PDFs, local documents, podcast feeds, and media URLs into readable summaries from one command.\n- Extract raw text, markdown, transcripts, timestamps, and slide OCR when you need source material for follow-up prompts or other tools.\n- Reuse the same pipeline behind a localhost daemon so a Chrome or Firefox side panel can summarize the current tab or media page.\n\n## Agent Fit\n- `--json`, stdin support, and explicit flags make it easy to wrap in scripts that fetch content, summarize it, then pass structured results downstream.\n- It works well as a read-only ingestion primitive when an agent needs to condense long pages or media before acting somewhere else.\n- Media-heavy and browser-side flows depend on configured models or API keys plus optional local tools like `ffmpeg`, `yt-dlp`, and `tesseract`.\n\n## Caveats\n- Output quality and supported attachment types vary by the chosen model or provider, so the same command is not equally reliable across backends.\n- The browser side-panel workflow is optional but requires a paired local daemon and token setup; CLI-only use does not.", "category": "ai-agents", "install": "npm install -g @steipete\/summarize", "github": "https:\/\/github.com\/steipete\/summarize", "website": "https:\/\/summarize.sh\/", "source_url": null, "stars": 4787, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "stern", "name": "stern", "description": "Kubernetes log tailing CLI for streaming and filtering logs across multiple pods and containers.", "long_description": "stern is a Kubernetes log tailing CLI for following logs across multiple pods and containers that match a regex, selector, or workload resource. It is built for cluster debugging when replicas churn and one `kubectl logs` call is not enough.\n\n## What It Enables\n- Stream logs from all pods behind a deployment, service, job, or regex match and keep following as pods are added, restarted, or replaced.\n- Reduce noisy log streams by namespace, label or field selector, container name or state, node, and include, exclude, or highlight regex filters.\n- Emit structured log records or custom templates for piping into `jq`, shell scripts, or other triage and reporting workflows.\n\n## Agent Fit\n- `--output json` emits one JSON object per log line with pod, namespace, container, node, labels, and annotations, and `--stdin` reuses the same templating path for piped logs.\n- Resource queries like `deployment\/name`, non-interactive flags, and automatic watch and retry behavior make it useful in inspect-then-filter incident loops.\n- It is inspection-only and depends on kubeconfig access plus live Kubernetes log APIs; the optional `--prompt` flow is interactive and not suitable for unattended runs.\n\n## Caveats\n- You need cluster credentials and log permissions in the target namespaces before stern can do anything useful.\n- Follow mode can open many concurrent log requests on busy workloads, so `--max-log-requests` may need tuning to avoid errors or excess load.", "category": "containers", "install": "brew install stern", "github": "https:\/\/github.com\/stern\/stern", "website": null, "source_url": null, "stars": 4552, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "az", "name": "Azure CLI", "description": "Official Microsoft Azure CLI for managing Azure resources, deployments, identities, and service APIs from the shell.", "long_description": "Azure CLI is Microsoft's official command line for Azure resource management, identity-aware authentication, and service operations across compute, storage, networking, deployments, and policy. It also exposes lower-level escape hatches like `az rest` and `az account get-access-token` when you need to script Azure or Microsoft Graph APIs directly.\n\n## What It Enables\n- Create, inspect, update, and delete Azure resources such as resource groups, virtual machines, storage accounts, networks, registries, and other service objects from one shell surface.\n- Run ARM or Bicep deployments, validate templates, execute What-If previews, query subscription state, and fetch access tokens for follow-up automation.\n- Use authenticated raw REST calls when the higher-level command surface is not enough, while still reusing current cloud, subscription, and credential context.\n\n## Agent Fit\n- Broad use of `--output` and `--query` makes results easy to parse in inspect\/change\/verify loops, and many commands return structured objects instead of human-only text.\n- Most operational commands are non-interactive once auth and subscription context are set, but `az login` can open a browser or launch interactive subscription selection with no JSON output.\n- Best for agents already operating in Azure-heavy environments that need one control surface spanning first-party services plus authenticated `az rest` fallbacks.\n\n## Caveats\n- Authentication and subscription selection can be interactive; service principal, managed identity, or device-code flows are safer choices for unattended runs.\n- The command surface is huge and defaults often favor local context or human-readable output, so stable automation should set explicit subscription, output, and non-interactive flags.", "category": "cloud", "install": "brew install azure-cli", "github": "https:\/\/github.com\/Azure\/azure-cli", "website": "https:\/\/learn.microsoft.com\/cli\/azure\/", "source_url": "https:\/\/learn.microsoft.com\/cli\/azure\/", "stars": 4469, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Microsoft Azure" }, { "slug": "icdiff", "name": "icdiff", "description": "Side-by-side colored diff CLI for comparing files and directories with clearer terminal review output.", "long_description": "icdiff is a text diff CLI that renders side-by-side, colorized comparisons for files and directory trees. It is mainly for review workflows where plain `diff` or default VCS output makes small line-level changes hard to read.\n\n## What It Enables\n- Compare two text files with inline change highlighting, custom labels, line numbers, whitespace controls, and whole-file or contextual views.\n- Compare directory trees, recurse into subdirectories, exclude path patterns, and optionally flag permission differences or identical files.\n- Use it as a Git, Subversion, or Mercurial difftool when reviewing working-tree changes from the terminal.\n\n## Agent Fit\n- Direct two-path invocation, script-friendly exit codes, and non-interactive flags make it easy to drop into inspect or verify steps.\n- Output is ANSI-colored plain text only, so agents cannot rely on structured parsing the way they could with JSON-emitting CLIs.\n- Best fit is human-in-the-loop review after an agent edits files, especially when a clearer side-by-side diff is more useful than raw patch output.\n\n## Caveats\n- It is text-oriented: invalid encodings and binary-like inputs surface errors instead of a rich comparison view.\n- Display quality depends on terminal width and ANSI color support; `--cols` and wrapping or truncation options may need tuning in automation.", "category": "dev-tools", "install": "python3 -m pip install icdiff", "github": "https:\/\/github.com\/jeffkaufman\/icdiff", "website": "https:\/\/www.jefftk.com\/icdiff", "source_url": "https:\/\/www.jefftk.com\/icdiff", "stars": 4355, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "firebase", "name": "Firebase CLI", "description": "Official Firebase CLI for deploys, local emulators, project and app management, and Firebase data, auth, and config workflows.", "long_description": "Firebase CLI is Firebase's official command surface for provisioning and operating Firebase projects from the shell. It spans project bootstrap, local emulation, deploys, and direct service management for apps, auth, databases, logs, and remote configuration.\n\n## What It Enables\n- Deploy Hosting, Functions, Remote Config, Auth, Data Connect, and other configured Firebase targets from a checked-in `firebase.json`.\n- Run local emulators and wrap test scripts with `emulators:start` or `emulators:exec` before shipping changes.\n- List projects and apps, read function logs, import or export Auth users, and read or write Realtime Database and Remote Config state from the shell.\n\n## Agent Fit\n- `-j, --json` is implemented at the CLI framework layer, and many inspect commands return structured objects or raw JSON for follow-up parsing.\n- It fits inspect, change, and verify loops well because the same tool can query project state, run local emulators, and deploy remote changes.\n- Credentials, browser login, default confirmations, and repo-local config assumptions still limit unattended use; the repo also ships `firebase mcp` for teams that want that integration model.\n\n## Caveats\n- Many high-value commands assume an existing Firebase project directory or an explicit `-P` project id.\n- Output is not uniformly machine-readable: deploy and emulator startup are still human-first status flows even though the CLI broadly supports JSON.", "category": "cloud", "install": "npm install -g firebase-tools", "github": "https:\/\/github.com\/firebase\/firebase-tools", "website": "https:\/\/firebase.google.com\/docs\/cli", "source_url": "https:\/\/firebase.google.com\/docs\/cli", "stars": 4351, "language": "TypeScript", "has_mcp": true, "has_skill": true, "has_json": true, "brand_icon": "google", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Firebase" }, { "slug": "dog-dns", "name": "doggo", "description": "DNS lookup CLI for querying records, reverse lookups, and resolver behavior across UDP, TCP, DoH, DoT, DoQ, and DNSCrypt.", "long_description": "doggo is a DNS query CLI for looking up records, reverse mappings, and resolver behavior across classic and encrypted transports. It helps inspect how names resolve through local or explicit resolvers, including remote vantage points via Globalping.\n\n## What It Enables\n- Query common and advanced DNS record types, plus PTR reverse lookups, against the system resolver or an explicit nameserver.\n- Compare answers across multiple resolvers and transports such as UDP, TCP, DoH, DoT, DoQ, and DNSCrypt when debugging resolution differences.\n- Capture answers, authority and additional sections, EDNS details, and optional Globalping measurements from specific regions.\n\n## Agent Fit\n- `--json` returns structured response objects with answers, questions, authorities, additional records, and EDNS metadata for follow-up parsing.\n- Commands are direct and non-interactive, so they fit inspect and verify loops in scripts, CI jobs, or agent troubleshooting sessions.\n- Scope stays read-only: useful for diagnosing DNS state, but not for editing zone records or provider configuration.\n\n## Caveats\n- Default output is a colored table, so unattended workflows should opt into `--json` or `--short`.\n- Globalping mode is more constrained than standard lookups: it allows only one target, one query type, and one resolver per measurement.", "category": "networking", "install": "curl -sS https:\/\/raw.githubusercontent.com\/mr-karan\/doggo\/main\/install.sh | sh", "github": "https:\/\/github.com\/mr-karan\/doggo", "website": "https:\/\/doggo.mrkaran.dev\/docs\/", "source_url": null, "stars": 4163, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "step", "name": "Smallstep CLI", "description": "PKI CLI for operating step-ca, issuing and inspecting X.509 or SSH certificates, and running related crypto and OAuth workflows.", "long_description": "step is Smallstep's PKI and certificate automation CLI. It works as both a client for step-ca or other ACME-compatible CAs and a local toolkit for inspecting certificates, issuing credentials, and handling adjacent crypto or OAuth tasks.\n\n## What It Enables\n- Bootstrap trust, request or renew X.509 certificates, revoke them, and inspect local files or remote TLS chains for PKI automation.\n- Generate SSH keys and short-lived SSH certificates, add them to the SSH agent, inspect them, and manage SSH login or renewal workflows.\n- Handle supporting identity operations such as JWT, JWS, JWE, and JWK processing, OAuth or OIDC token acquisition, and CA context management.\n\n## Agent Fit\n- Structured output exists where inspection matters most, including JSON modes for certificate inspection, SSH certificate inspection, JWS verification or inspection, and current context lookup.\n- Most commands are flag-driven and scriptable, but unattended use often requires preloaded roots, tokens, password files, an SSH agent, or a configured CA context.\n- It fits agents best in known PKI environments where issuance, renewal, and verification steps are already modeled; the CLI is less uniform than tools with one global JSON contract.\n\n## Caveats\n- Many core workflows assume a reachable step-ca or compatible CA and the right provisioner or trust bootstrap already in place.\n- OAuth and some enrollment paths can open a browser or fall back to prompts unless you choose console modes and non-interactive credential flags.", "category": "security", "install": "brew install step", "github": "https:\/\/github.com\/smallstep\/cli", "website": "https:\/\/smallstep.com\/docs\/step-cli\/", "source_url": "https:\/\/smallstep.com\/cli", "stars": 4149, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Smallstep" }, { "slug": "ssh-audit", "name": "ssh-audit", "description": "SSH security audit CLI for checking server or client algorithms, policies, and hardening posture.", "long_description": "ssh-audit inspects SSH servers and clients for supported algorithms, host keys, protocol behavior, and hardening posture. It can run standard audits, policy checks, client-side audits, and built-in hardening guide lookups from one command.\n\n## What It Enables\n- Scan an SSH server to enumerate banners, key exchanges, host keys, ciphers, MACs, fingerprints, and version-compatibility issues.\n- Audit many hosts from a targets file, generate a baseline policy from a known-good system, and check other servers or clients against built-in or custom policies.\n- Inspect client SSH configurations by running a temporary listener, and retrieve built-in hardening guides or algorithm lookups without leaving the terminal.\n\n## Agent Fit\n- `-j\/--json` provides structured audit output, including JSON arrays for multi-target scans and structured policy results that are straightforward to parse.\n- Batch flags, target files, thread control, and explicit exit codes for good, warning, failure, connection error, and unknown error make it usable in CI and verification loops.\n- Best for inspect-and-enforce workflows around SSH posture; remediation still happens by changing server or client configs outside the tool.\n\n## Caveats\n- It operates against live network targets, and client audits open a listening socket locally, so automation needs the right reachability and permissions.\n- `--dheat` is an active denial-of-service test, so it should only be used against systems you are authorized to stress.", "category": "security", "install": "pip install ssh-audit", "github": "https:\/\/github.com\/jtesta\/ssh-audit", "website": "https:\/\/www.ssh-audit.com\/", "source_url": null, "stars": 4120, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "stack", "name": "Stack", "description": "Haskell project CLI for creating projects, managing GHC toolchains and dependencies, and building, testing, or running packages.", "long_description": "Stack is a Haskell project workflow CLI that combines toolchain setup, dependency resolution, builds, and project commands around a `stack.yaml` snapshot. It is built for reproducible local development and CI in Haskell codebases rather than general system package management.\n\n## What It Enables\n- Create or initialize Haskell projects, pin them to a snapshot, and install the GHC version and supporting tools they need.\n- Build, test, benchmark, document, and run project packages or selected components from one CLI.\n- Inspect dependency sets, build paths, and project metadata for debugging, environment setup, or follow-up automation.\n\n## Agent Fit\n- Most commands are non-interactive and project-scoped, which makes Stack workable in CI and agent loops for build, test, run, and environment setup.\n- Structured output exists but is narrow: `stack ls dependencies json` emits JSON and `stack query` emits YAML, while much of the rest of the surface is text-first.\n- Best fit when an agent already has a checked-out Haskell project and needs to validate builds, run executables, or inspect the Stack environment.\n\n## Caveats\n- First runs can download GHC, package indexes, or MSYS2, so automation is slower and more environment-sensitive than simpler language CLIs.\n- The documented Homebrew formula is unofficial and can lag new releases; the direct installer or release binaries are the canonical paths.", "category": "package-managers", "install": "curl -sSL https:\/\/get.haskellstack.org\/ | sh", "github": "https:\/\/github.com\/commercialhaskell\/stack", "website": "https:\/\/docs.haskellstack.org", "source_url": "https:\/\/haskellstack.org", "stars": 4049, "language": "Haskell", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "boundary", "name": "Boundary CLI", "description": "HashiCorp CLI for authenticating to Boundary, managing access resources, and opening proxied sessions to targets.", "long_description": "Boundary CLI is HashiCorp's command line for Boundary's access-control plane and client connection flows. It manages auth methods, identities, targets, workers, credentials, sessions, and session recordings, then can authorize or launch proxied connections through Boundary.\n\n## What It Enables\n- Authenticate with password, LDAP, or OIDC methods, manage local token handling, and inspect client-agent state for a Boundary environment.\n- Create, read, update, delete, and list Boundary resources such as scopes, users, groups, roles, hosts, host sets, targets, workers, credential stores, credential libraries, and storage or recording resources.\n- Authorize sessions and open proxied connections to SSH, RDP, database, Kubernetes, HTTP, and other supported targets, then inspect, cancel, or download session and recording data.\n\n## Agent Fit\n- Control-plane commands follow predictable `read`, `list`, `create`, `update`, and `delete` patterns, and `-format json` makes inspect\/change\/verify loops straightforward.\n- Secrets and structured attributes can come from `env:\/\/`, `file:\/\/`, and JSON maps, which helps non-interactive automation.\n- Automation gets weaker around browser or prompt-driven auth and `connect` flows that hand off to local clients or long-lived tunnels; there is no native MCP or packaged skills tree.\n\n## Caveats\n- Useful only against a running Boundary deployment with configured auth methods, targets, workers, and often external systems such as an IdP or Vault.\n- This repo contains the full Boundary product, so canonical install and CLI reference guidance lives on the HashiCorp Developer site rather than only in the README.", "category": "security", "install": "brew tap hashicorp\/tap && brew install hashicorp\/tap\/boundary", "github": "https:\/\/github.com\/hashicorp\/boundary", "website": "https:\/\/developer.hashicorp.com\/boundary\/docs\/commands", "source_url": "https:\/\/boundaryproject.io", "stars": 4004, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "HashiCorp" }, { "slug": "git-secret", "name": "git-secret", "description": "Git secrets CLI for encrypting tracked files with GPG, managing who can decrypt them, and revealing them in local or CI workflows.", "long_description": "git-secret adds GPG-backed encryption to a normal Git repo so teams can keep encrypted secret files in version control and reveal them only for authorized keys. It centers on tracked files, repo-local keyring metadata, and simple subcommands for hiding, revealing, sharing, and auditing secrets.\n\n## What It Enables\n- Track specific files as secrets, encrypt them into `.secret` blobs, and commit the encrypted versions alongside the rest of the repository.\n- Add or remove collaborators' GPG keys, list who can decrypt the repo, and re-encrypt files when access changes.\n- Reveal secrets into the working tree, print decrypted contents to stdout, or diff current plaintext against encrypted versions during review or CI.\n\n## Agent Fit\n- The command set maps cleanly to inspect\/change\/verify loops: `list` and `whoknows` inspect, `tell` and `removeperson` change access, and `changes` verifies drift.\n- Automation is workable because `reveal`, `cat`, and `changes` accept a passphrase and custom GPG home, but output stays plain text and diffs rather than structured JSON.\n- Best for repositories that intentionally keep encrypted config in Git; less useful when secrets already live in a dedicated secret manager.\n\n## Caveats\n- Every machine or CI runner that decrypts secrets needs compatible GPG keys and keyring setup.\n- Adding or removing recipients does not retroactively update existing encrypted files; someone with access still has to re-encrypt them.", "category": "security", "install": "brew install git-secret", "github": "https:\/\/github.com\/sobolevn\/git-secret", "website": "https:\/\/git-secret.io\/", "source_url": "https:\/\/git-secret.io\/", "stars": 3988, "language": "Shell", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "pgbouncer", "name": "PgBouncer", "description": "PostgreSQL connection pooler with admin-console commands for inspecting pools, clients, servers, and connection state.", "long_description": "PgBouncer is a lightweight PostgreSQL connection pooler that sits between applications and PostgreSQL to reuse backend connections and cap connection churn. Its operational surface is the `pgbouncer` daemon plus a special admin database that exposes `SHOW` and control commands.\n\n## What It Enables\n- Run session, transaction, or statement pooling in front of PostgreSQL to reduce connection overhead and limit backend fan-out.\n- Inspect live pools, clients, servers, DNS cache, socket state, and traffic counters through admin `SHOW` commands when diagnosing saturation or routing issues.\n- Pause, resume, reconnect, reload, kill, and controlled-shutdown PgBouncer during database restarts, failovers, and config rollouts.\n\n## Agent Fit\n- Agents can drive it non-interactively by starting `pgbouncer` with flags and sending admin SQL commands through `psql` or another PostgreSQL client.\n- No native JSON output was found, so inspection workflows depend on parsing SQL result sets or client-formatted text.\n- Best fit for Postgres operations loops where an agent needs to inspect pool state, apply a control action, and verify the result.\n\n## Caveats\n- Most day-two operations are not top-level CLI subcommands; they require connecting to the `pgbouncer` admin database with an allowed user.\n- The admin console only supports the simple query protocol, so some drivers will not work unless they can send simple SQL.", "category": "databases", "install": "brew install pgbouncer", "github": "https:\/\/github.com\/pgbouncer\/pgbouncer", "website": "https:\/\/www.pgbouncer.org\/", "source_url": "https:\/\/www.pgbouncer.org\/", "stars": 3963, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "wrangler", "name": "Wrangler", "description": "Official Cloudflare CLI for developing and operating Workers projects plus Pages, KV, D1, R2, Queues, and related resources.", "long_description": "Wrangler is Cloudflare's command-line tool for building, deploying, and operating Workers projects and related Cloudflare developer-platform resources. It combines local dev and deployment flows with account-level commands for Pages, KV, D1, R2, Queues, versions, and log tails.\n\n## What It Enables\n- Start local Worker or Pages dev flows, bundle code, generate types, and deploy new revisions from the shell.\n- Inspect and change Cloudflare resources such as Worker versions and secrets, Pages projects and deployments, KV namespaces and keys, D1 databases and migrations, R2 buckets and objects, and Queues.\n- Tail logs, list recent deployments, and capture deployment metadata for follow-up automation without switching to the dashboard.\n\n## Agent Fit\n- The command tree is broad and mostly non-interactive once auth and config are in place, so agents can drive inspect-change-verify loops directly from shell commands.\n- Structured output is real but uneven: many read paths support `--json` or `--format json`, and deploy workflows can emit machine-readable event files, but some commands still default to tables or human text.\n- Browser OAuth login, credential requirements, and a few prompt-heavy flows around setup, deploy, or version rollout mean unattended use works best with pre-provisioned API tokens and explicit flags.\n\n## Caveats\n- Wrangler is tightly coupled to Cloudflare account state and project config, so useful automation usually requires `wrangler.jsonc` plus account credentials.\n- JSON coverage is not universal across the command tree, so some workflows still need carefully chosen commands or text parsing.", "category": "cloud", "install": "npm install --save-dev wrangler@latest", "github": "https:\/\/github.com\/cloudflare\/workers-sdk", "website": "https:\/\/developers.cloudflare.com\/workers\/wrangler\/", "source_url": null, "stars": 3860, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "cloudflare", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Cloudflare" }, { "slug": "crane", "name": "crane", "description": "Container registry CLI for inspecting image metadata, copying images, and modifying remote OCI image references.", "long_description": "Crane is Google's CLI for working directly with container registries and remote OCI images. It covers the registry-side operations around inspection, copy, tagging, export or import, and targeted image mutation without requiring a local Docker daemon.\n\n## What It Enables\n- Inspect remote image manifests, configs, digests, tags, and registry catalogs, then export filesystems or pull images into tarballs or OCI layouts.\n- Copy, retag, delete, validate, and push images across registries while preserving digests where the registry-side operation allows it.\n- Append layers, mutate labels or annotations or entrypoints, filter multi-platform indexes, assemble new indexes, and rebase images onto patched base layers.\n\n## Agent Fit\n- Manifest, config, and auth read paths are already machine-readable, and commands like `push`, `append`, `index filter`, and `rebase` print resulting references that chain cleanly into shell pipelines.\n- Most subcommands are direct non-interactive operations, so they fit inspect or change or verify loops in CI, release tooling, and registry automation.\n- Structured output is not uniform across the whole CLI, and remote-state commands still depend on registry credentials, network access, and guardrails around risky operations like `rebase`.\n\n## Caveats\n- Most useful workflows target remote registries rather than local daemon state, so authentication and network reachability are prerequisites.\n- `crane rebase` is documented as experimental and not safe in general; rebased images should be validated before promotion.", "category": "containers", "install": "go install github.com\/google\/go-containerregistry\/cmd\/crane@latest", "github": "https:\/\/github.com\/google\/go-containerregistry", "website": null, "source_url": "https:\/\/github.com\/google\/go-containerregistry", "stars": 3763, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Google" }, { "slug": "gojq", "name": "gojq", "description": "Pure Go implementation of jq for JSON querying, filtering, and transformations in portable scripts.", "long_description": "gojq is a portable `jq` implementation for querying and transforming structured data from stdin or files, with optional YAML input and output support. It is mainly a shell primitive for inspecting and reshaping JSON between other commands.\n\n## What It Enables\n- Extract fields, filter arrays, and reshape API responses, logs, or config files inside shell pipelines.\n- Read JSON or YAML from stdin or files, apply jq-style expressions, and emit JSON, compact JSON, raw strings, or YAML for downstream steps.\n- Build repeatable data-processing steps with query files, variable injection, slurp and stream modes, and file-based module loading.\n\n## Agent Fit\n- stdin and stdout behavior is predictable, flags are non-interactive, and `--exit-status` helps scripts branch on query results.\n- Structured output is a core strength here: JSON is the default stdout format, with compact and raw modes available when shell composition needs them.\n- Best used as glue alongside service CLIs or HTTP calls, where an agent needs to inspect, normalize, or transform structured payloads before the next command.\n\n## Caveats\n- Compatibility is close to `jq` but not exact: the README documents missing flags, unsupported functions, and differences such as object key ordering behavior.\n- This is a data-processing primitive, not a service CLI, so it only becomes useful in a larger workflow when paired with other commands or files.", "category": "data-processing", "install": "brew install gojq", "github": "https:\/\/github.com\/itchyny\/gojq", "website": null, "source_url": "https:\/\/github.com\/itchyny\/gojq", "stars": 3714, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "gcalcli", "name": "gcalcli", "description": "Google Calendar CLI for listing calendars, querying events, adding or importing events, and running reminders from the terminal.", "long_description": "gcalcli is a community-maintained CLI for working with Google Calendar from the shell. It focuses on event lookup, calendar views, event creation or import, and reminder automation rather than broader Google Workspace administration.\n\n## What It Enables\n- List calendars and query upcoming, updated, or conflicting events across selected calendars, including agenda and calendar-style views.\n- Create events with quick-add or detailed fields, delete or edit matched events, and import ICS or vCal invites into a calendar.\n- Run reminder commands before upcoming events and script calendar lookups for cron jobs, shell workflows, or follow-up tooling.\n\n## Agent Fit\n- Event query commands expose real `--json` and `--tsv` output, which makes search, agenda, updates, conflicts, and calendar views workable in inspect-then-act loops.\n- The command surface is shell-friendly once auth is in place: commands are flag-driven, calendar selection can be configured, and reminders can hand off to another command.\n- Automation still has friction: initial auth requires your own Google Cloud OAuth client plus browser approval, `edit` stays interactive, and `delete` only becomes headless with `--iamaexpert`.\n\n## Caveats\n- You need to create your own Google Calendar API OAuth client and complete a browser-based consent flow before most commands work.\n- Some mutation paths are human-first: `edit` always prompts, `delete` prompts unless you bypass it, and verbose imports can ask for confirmation per event.", "category": "google-workspace", "install": "brew install gcalcli", "github": "https:\/\/github.com\/insanum\/gcalcli", "website": null, "source_url": null, "stars": 3658, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "google", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "catt", "name": "catt", "description": "Chromecast control CLI for discovering devices, casting online or local media or web pages, and managing playback.", "long_description": "catt is a Chromecast control CLI for discovering devices on your local network, launching media on them, and sending playback commands from the shell. It covers both one-off casting and ongoing control of TVs, speakers, and speaker groups that expose the Chromecast protocol.\n\n## What It Enables\n- Discover Chromecast devices on the local network and inspect their IPs, model metadata, and current playback details.\n- Cast supported online videos, direct media URLs, local audio, video, or image files, subtitles, or arbitrary web pages to Chromecast targets.\n- Pause, resume, seek, adjust volume, manage YouTube queues, and save or restore playback state from scripts.\n\n## Agent Fit\n- Most commands are direct and non-interactive, so agents can use it as a simple control surface once a target device is known.\n- Machine-readable output exists for device scans and playback info via `scan -j` and `info -j`, but the rest of the command surface is mostly plain text.\n- Best suited to local media, signage, or home automation loops rather than broad service automation, because everything depends on LAN-reachable Chromecast hardware.\n\n## Caveats\n- Discovery and control only work when the calling machine can reach the Chromecast on the local network.\n- Casting local files starts a temporary local HTTP server, so firewall rules and the documented TCP port range 45000-47000 matter.", "category": "media", "install": "pipx install catt", "github": "https:\/\/github.com\/skorokithakis\/catt", "website": null, "source_url": "https:\/\/github.com\/skorokithakis\/catt", "stars": 3633, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "curlie", "name": "curlie", "description": "HTTP request CLI that keeps curl's option surface while adding HTTPie-style request syntax and terminal-friendly formatting.", "long_description": "Curlie is a thin frontend over `curl` that accepts HTTPie-style request items while preserving almost all of curl's flags. It is built for one-shot HTTP and API work where shorter request syntax and nicer terminal output help more than a higher-level client abstraction.\n\n## What It Enables\n- Send ad hoc HTTP requests with `METHOD URL`, `header:value`, `query==value`, and `field=value` syntax while still passing curl flags for auth, TLS, proxies, retries, uploads, and transfer control.\n- Inspect API responses with pretty-printed JSON bodies, colored headers on stderr, and separate body output on stdout that can still be piped into other shell steps.\n- Print the exact underlying `curl` command with `--curl` to debug a request or turn an exploratory step into a plain curl invocation.\n\n## Agent Fit\n- Useful when an agent wants curl's mature transport features but a shorter surface for composing one-off HTTP requests.\n- Machine-readability is limited: the project does not expose a structured output mode, and JSON support is only terminal formatting layered on top of whatever the server returns.\n- Automation needs explicit flags because defaults are terminal-oriented; non-TTY stdin is treated as request input and header or URL diagnostics are written to stderr.\n\n## Caveats\n- Curlie executes the local `curl` binary, so available protocol features and some behavior depend on the curl version installed on the host.\n- The nicest output path is interactive terminal use; pretty printing and header rendering are optimized for human inspection rather than clean machine parsing.", "category": "http-apis", "install": "brew install curlie", "github": "https:\/\/github.com\/rs\/curlie", "website": "https:\/\/rs.github.io\/curlie\/", "source_url": null, "stars": 3595, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "ghq", "name": "ghq", "description": "Repository checkout manager for cloning, listing, and relocating repos under deterministic local paths.", "long_description": "ghq manages local repository checkouts by mapping remote URLs to predictable paths under one or more roots. It is mainly used to clone, find, and reorganize many repos without remembering where each checkout lives.\n\n## What It Enables\n- Clone or update repositories from shorthand names, full URLs, or stdin into a consistent `host\/user\/repo` directory layout.\n- List local checkouts by query, exact match, VCS, unique subpath, or full path so shell tools can jump to the right repo.\n- Create empty local repos, remove stale clones, or migrate existing checkouts into the managed layout.\n\n## Agent Fit\n- Predictable paths and simple stdout output make it useful as plumbing around clone, search, and repo-selection workflows.\n- Commands are non-TUI and mostly scriptable, but output is plain text only; there is no JSON or other structured mode.\n- Best used alongside `git`, code search, and task CLIs when an agent needs a stable local checkout layout across many repositories.\n\n## Caveats\n- `rm` prompts for confirmation and `get --look` opens an interactive shell, so some flows are not unattended by default.\n- `create` initializes a local repo only; it does not provision a remote repository on GitHub or another host.", "category": "github", "install": "brew install ghq", "github": "https:\/\/github.com\/x-motemen\/ghq", "website": null, "source_url": "https:\/\/github.com\/x-motemen\/ghq", "stars": 3508, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "atac", "name": "ATAC", "description": "Terminal API client for building, sending, and organizing HTTP or WebSocket requests in local collections.", "long_description": "ATAC is an offline terminal API client that combines a full-screen TUI with subcommands for saved-request and one-shot API work. It covers HTTP and WebSocket requests, local environments, and imported collections without tying data to a hosted account.\n\n## What It Enables\n- Create local JSON or YAML API collections and environment files, then edit or inspect saved requests from the shell or TUI.\n- Send one-shot or saved HTTP and WebSocket requests with params, headers, auth, bodies, scripts, and response inspection.\n- Import Postman, cURL, or OpenAPI inputs and export saved requests as cURL, raw HTTP, PHP Guzzle, Axios, or Reqwest snippets.\n\n## Agent Fit\n- Useful when an agent needs an offline API workspace with explicit commands for collections, requests, environments, and ad hoc `try` requests.\n- Automation fit is limited by human-formatted stdout and the lack of `--json`, so follow-up parsing is brittle compared with API CLIs that emit structured results.\n- Best for interactive API exploration or local request libraries that an agent can drive; less ideal for unattended pipelines or machine-first response processing.\n\n## Caveats\n- The product's center of gravity is still the fullscreen TUI, and some workflows like WebSocket messaging become interactive loops after connection.\n- Auth coverage is partial compared with Postman-style tools; README explicitly marks OAuth1 or OAuth2 and AWS auth as missing.", "category": "http-apis", "install": "cargo install atac --locked", "github": "https:\/\/github.com\/Julien-cpsn\/ATAC", "website": "https:\/\/atac.julien-cpsn.com\/", "source_url": null, "stars": 3490, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "silicon", "name": "silicon", "description": "CLI for rendering syntax-highlighted code snippets into styled PNG screenshots from files, stdin, or the clipboard.", "long_description": "silicon renders syntax-highlighted code into styled PNG screenshots. It is a browser-free alternative to Carbon for documentation, blog, and sharing workflows.\n\n## What It Enables\n- Render source files or piped snippets into code images for docs, blog posts, release notes, or social sharing.\n- Generate consistent screenshots in scripts with theme, font, padding, line-number, highlighted-line, window-title, and background controls.\n- Pull code from the clipboard and copy the finished image back to the clipboard for editor-centric publishing workflows.\n\n## Agent Fit\n- File and stdin input plus explicit flags make it easy to batch-generate screenshots in shell scripts or docs pipelines.\n- The automation surface is narrow: output is a PNG file or clipboard image only, with no JSON or text mode for downstream parsing.\n- Best fit when an agent already knows which snippet to present and needs a polished asset rather than system inspection or mutation.\n\n## Caveats\n- Clipboard workflows depend on platform-specific integration such as macOS pasteboard, `wl-copy`, or `xclip`.\n- Custom syntaxes and themes rely on local cache files and may need an explicit cache rebuild.", "category": "dev-tools", "install": "brew install silicon", "github": "https:\/\/github.com\/Aloxaf\/silicon", "website": null, "source_url": null, "stars": 3477, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "mc", "name": "MinIO Client", "description": "Official MinIO client for S3-compatible object storage operations, mirroring, and admin tasks.", "long_description": "`mc` is the official MinIO client for working with buckets and objects across MinIO, other S3-compatible services, and local filesystems. Beyond copy and listing primitives, it also exposes MinIO-specific administration for replication, lifecycle, IAM, and diagnostics.\n\n## What It Enables\n- Copy, sync, move, diff, and delete objects between local filesystems and S3-compatible buckets, including recursive mirrors and filtered transfers.\n- Inspect object metadata, query object contents with S3 Select, watch bucket or filesystem events, and generate temporary share links for upload or download flows.\n- Administer MinIO deployments from the shell: manage users, policies, replication, lifecycle, encryption, health, traces, and support diagnostics.\n\n## Agent Fit\n- Global `--json` support emits JSON Lines output, and core commands stay flag-driven and non-interactive, which works well in inspect, change, and verify loops.\n- Alias configuration, credentials, and certificate trust handling add setup friction before unattended automation is smooth.\n- Fit is strongest for scripted object operations and MinIO admin jobs; some support and observability commands open richer terminal dashboards unless you switch to JSON or raw stdout.\n\n## Caveats\n- The broad admin surface is MinIO-specific; against third-party S3 services, `mc` is mainly an object storage operations client.\n- Public docs linked from the repo now redirect to AIStor enterprise documentation, which covers features not all present in this open source repo.", "category": "cloud", "install": "brew install minio\/stable\/mc", "github": "https:\/\/github.com\/minio\/mc", "website": null, "source_url": "https:\/\/min.io\/download", "stars": 3406, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "MinIO" }, { "slug": "doctl", "name": "doctl", "description": "Official DigitalOcean CLI for managing droplets, Kubernetes, apps, DNS, registries, databases, and network resources.", "long_description": "doctl is DigitalOcean's official CLI for managing account, compute, networking, app platform, Kubernetes, database, and registry resources from the shell. It combines direct API-style CRUD operations with workflow helpers like kubeconfig generation, Docker registry login, and app log or console access.\n\n## What It Enables\n- Create, inspect, update, and delete DigitalOcean resources such as Droplets, load balancers, firewalls, VPCs, DNS records, databases, apps, and registries.\n- Fetch kubeconfig, manage DOKS clusters and node pools, and log Docker into Container Registry so follow-up tools like `kubectl` and Docker can operate with the current account context.\n- Tail app logs, start app console sessions, manage deployments or serverless resources, and inspect account, billing, and action history from the terminal.\n\n## Agent Fit\n- Global `--output json` plus a consistent noun-verb command structure make inspect, change, and verify loops straightforward.\n- Most operational commands are usable non-interactively once credentials are in place, and explicit `--force`, `--wait`, retry, and context flags help unattended automation.\n- The weakest spots are setup and live-session flows: `auth init` prompts for a token, some deletes ask for confirmation, and console or streaming commands are less automation-friendly than plain resource CRUD.\n\n## Caveats\n- You need a DigitalOcean API token and local auth context; `auth init` expects a real terminal unless you pass a token via flags or environment.\n- Some commands mainly hand off to other tools or live sessions, such as Docker registry login, kubeconfig setup for `kubectl`, and app console or log streaming.", "category": "cloud", "install": "brew install doctl", "github": "https:\/\/github.com\/digitalocean\/doctl", "website": "https:\/\/docs.digitalocean.com\/reference\/doctl\/", "source_url": "https:\/\/docs.digitalocean.com\/reference\/doctl\/", "stars": 3402, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "digitalocean", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "DigitalOcean" }, { "slug": "commitizen", "name": "Commitizen", "description": "Git workflow CLI for conventional commits, commit linting, semantic version bumps, and changelog generation.", "long_description": "Commitizen is a Git workflow CLI for teams that want structured commit messages and release metadata derived from commit history. Beyond the interactive `cz commit` flow, it also validates commit messages, calculates semantic version bumps, and writes changelogs from repo state.\n\n## What It Enables\n- Create guided conventional commits, or write the generated commit message to a file for wrapper scripts and hooks.\n- Validate a single message, a commit-msg file, or a revision range in CI before merging or releasing.\n- Calculate the next release version, update version files and tags, and generate changelog content from Git history.\n\n## Agent Fit\n- Works well in repo-local automation for commit linting and release steps because `cz check`, `cz bump`, `cz changelog`, and `cz version` have stable flags, stdout output, and documented exit codes.\n- Machine-readable output is limited: there is no JSON mode, so agents mostly rely on plain text, stdout-only flags like `--get-next` or `--changelog-to-stdout`, and exit status.\n- Mixed fit overall: useful once a repo is already configured around conventional commits, but `cz commit` and `cz init` are questionary-driven interactive flows rather than unattended primitives.\n\n## Caveats\n- Most commands expect a Git repo plus Commitizen configuration or a version provider, so usefulness depends on project setup and tag history.\n- `cz bump` can still prompt when no matching tag is found unless configuration is already in place or `--yes` is used.", "category": "github", "install": "pipx install commitizen", "github": "https:\/\/github.com\/commitizen-tools\/commitizen", "website": "https:\/\/commitizen-tools.github.io\/commitizen\/", "source_url": "https:\/\/commitizen-tools.github.io\/commitizen\/", "stars": 3323, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "kubectl", "name": "kubectl", "description": "Kubernetes CLI for inspecting resources, applying manifests, managing kubeconfig, and operating workloads.", "long_description": "kubectl is the official command line client for talking to the Kubernetes API server and working with cluster state. It covers day-to-day inspection, apply and delete workflows, kubeconfig management, workload access, and cluster debugging.\n\n## What It Enables\n- Inspect resources, events, logs, current identity, API schema, and raw cluster responses across namespaces and contexts.\n- Apply, diff, patch, scale, label, annotate, and delete resources from files, stdin, or live targets, then wait for rollout or status conditions.\n- Operate workloads directly from the terminal with `exec`, `logs`, `cp`, `port-forward`, `proxy`, and kubeconfig context management commands.\n\n## Agent Fit\n- Wide output support including `json`, `yaml`, `jsonpath`, custom columns, and name output makes read paths easy to parse or narrow for follow-up steps.\n- Most commands are stable and non-interactive once credentials are in place, and dry-run, diff, and wait flows fit shell-based inspect-change-verify loops well.\n- The main limits are environmental rather than CLI design: agents still need a valid kubeconfig, reachable clusters, appropriate RBAC, and sometimes external cloud auth plugins.\n\n## Caveats\n- Useful operation depends on kubeconfig, cluster reachability, and the permissions attached to the active context.\n- Some managed-cluster logins require separate provider plugins because built-in cloud auth integrations were removed from kubectl.", "category": "containers", "install": "brew install kubectl", "github": "https:\/\/github.com\/kubernetes\/kubectl", "website": "https:\/\/kubernetes.io\/docs\/reference\/kubectl\/", "source_url": "https:\/\/kubernetes.io\/docs\/reference\/kubectl\/", "stars": 3231, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "kubernetes", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Kubernetes" }, { "slug": "glab", "name": "glab", "description": "Official GitLab CLI for merge requests, issues, pipelines, releases, and API calls.", "long_description": "glab is GitLab's official CLI for working with GitLab projects and account resources from the shell. It covers merge requests and issues, CI\/CD, releases, repo operations, tokens and keys, and raw API access across GitLab.com and self-managed instances.\n\n## What It Enables\n- List, review, create, approve, merge, and comment on merge requests and issues without leaving the terminal.\n- Inspect and change pipelines, jobs, schedules, releases, variables, runners, and project metadata, or fall back to `glab api` for direct REST and GraphQL calls.\n- Authenticate against GitLab.com or self-managed instances and run the same workflows in local scripts or CI with personal tokens or job tokens.\n\n## Agent Fit\n- Many read paths expose `--output json`, and `glab api` adds `json` and `ndjson`, so follow-up parsing with shell tools is straightforward.\n- The command surface is broad enough for inspect, change, and verify loops across merge requests, issues, pipelines, releases, and repository metadata from one CLI.\n- It can also expose a stdio MCP server with `glab mcp serve`, but that path is explicitly experimental and secondary to the CLI itself.\n\n## Caveats\n- Useful automation still depends on GitLab credentials and often repository context; browser login and prompts are the default unless you switch to token-based auth or disable prompts.\n- `glab mcp` is documented as experimental and not ready for production use.", "category": "github", "install": "brew install glab", "github": "https:\/\/gitlab.com\/gitlab-org\/cli", "website": "https:\/\/docs.gitlab.com\/editor_extensions\/gitlab_cli\/", "source_url": "https:\/\/docs.gitlab.com\/editor_extensions\/gitlab_cli\/", "stars": 3200, "language": "Go", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": "gitlab", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "GitLab" }, { "slug": "mtr", "name": "mtr", "description": "Network path diagnostic CLI that combines ping and traceroute to measure loss and latency hop by hop.", "long_description": "mtr is a network path diagnostic CLI that continuously probes the route between your machine and a destination host. It combines traceroute-style hop discovery with ping-style latency and loss measurement so you can see where path quality degrades.\n\n## What It Enables\n- Inspect packet loss, latency, jitter, and hop-by-hop path behavior while troubleshooting slow or unreliable network routes.\n- Run one-shot reports or emit JSON, CSV, XML, raw, or split output for scripts, logging, incident notes, or post-change verification.\n- Test different probe protocols and path assumptions by choosing ICMP, UDP, TCP, or SCTP plus interface, source address, TTL, MPLS, and AS lookup options.\n\n## Agent Fit\n- Report mode and structured output give agents a workable inspect surface for path diagnostics, especially when they need per-hop numbers rather than a simple reachability answer.\n- JSON support is real, but it depends on builds that include Jansson, and the default experience is still a live curses UI rather than a pure batch-first command.\n- Best for network investigation and verification loops; it observes path health but does not remediate the network state it uncovers.\n\n## Caveats\n- Raw packet access requires capabilities, root, or a setuid helper, so permissions and local security policy can block or complicate automation.\n- Because `mtr` actively sends repeated probes, it is better for targeted diagnostics than for broad unattended monitoring against many destinations.", "category": "networking", "install": "brew install mtr", "github": "https:\/\/github.com\/traviscross\/mtr", "website": "https:\/\/www.bitwizard.nl\/mtr\/", "source_url": null, "stars": 3149, "language": "C", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "tcpdump", "name": "tcpdump", "description": "Packet capture CLI for filtering, inspecting, and saving network traffic to debug protocols, connectivity, and on-wire behavior.", "long_description": "tcpdump is a packet capture and decode CLI for inspecting live network traffic or reading saved packet traces. It sits close to the wire: you filter traffic with `pcap` expressions, print protocol details, or write raw packets to capture files for later analysis.\n\n## What It Enables\n- Capture traffic on a chosen interface and narrow it with `pcap` filter expressions so you can isolate DNS, HTTP, TLS, VPN, or host-to-host flows during outages and protocol debugging.\n- Read existing `pcap` or `pcapng` files, print decoded packet details, or emit matching packet counts when you need scripted inspection of saved traces.\n- Write raw captures to files, rotate them by size or time, and hand them off to Wireshark or follow-up CLI analysis during longer investigations.\n\n## Agent Fit\n- Non-interactive flags, filter expressions, buffered stdout controls, and documented exit codes make it usable in scripted inspect-then-verify loops.\n- It is especially useful when an agent needs raw network evidence: capture now, reread the file with tighter filters later, or use `--count` for simple scalar checks on saved captures.\n- Parsed output is human-oriented text rather than structured JSON, and live capture often needs elevated privileges plus networking knowledge to avoid noisy or incomplete traces.\n\n## Caveats\n- Capturing from live interfaces may require root or capture privileges; reading saved packet files does not.\n- Snapshot length, buffering, and rotation settings affect fidelity and packet loss, so automation is usually safer when it saves capture files instead of parsing console text alone.", "category": "networking", "install": "brew install tcpdump", "github": "https:\/\/github.com\/the-tcpdump-group\/tcpdump", "website": "https:\/\/www.tcpdump.org\/", "source_url": "https:\/\/www.tcpdump.org\/", "stars": 3141, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "dotnet", "name": "dotnet CLI", "description": "Official .NET SDK CLI for creating projects, building and testing code, managing packages and tools, and publishing apps.", "long_description": "dotnet is the command surface for the .NET SDK. It covers the core lifecycle of a .NET codebase, from project creation and restore through build, test, packaging, tool management, workloads, and publish.\n\n## What It Enables\n- Scaffold new apps, libraries, solutions, and config files from templates, then restore dependencies and create a working project layout from the shell.\n- Build, run, test, pack, and publish .NET projects in local development loops or CI without leaving the terminal.\n- Inspect and manage NuGet packages, install local or global .NET tools, and add optional SDK workloads such as MAUI-related components.\n\n## Agent Fit\n- Useful as the primary inspect-change-verify loop inside .NET repos because the same CLI handles restore, build, test, publish, package, tool, and workload operations.\n- Structured output is real but partial: package inspection and search support JSON, while core build, test, and publish flows still emit mostly human-oriented logs.\n- Automation depends on environment context because SDK selection can follow `global.json`, some commands restore implicitly, and package or workload operations may require credentials, prompts, or elevated rights.\n\n## Caveats\n- Behavior varies by installed SDK version and command form, with several docs calling out differences between .NET 6 through .NET 10.\n- Some higher-level commands can download manifests, open authentication flows, or modify project state as part of otherwise routine operations.", "category": "package-managers", "install": "brew install --cask dotnet-sdk", "github": "https:\/\/github.com\/dotnet\/sdk", "website": "https:\/\/learn.microsoft.com\/en-us\/dotnet\/core\/tools\/", "source_url": "https:\/\/learn.microsoft.com\/en-us\/dotnet\/core\/tools\/", "stars": 3068, "language": "C#", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": ".NET" }, { "slug": "amplify", "name": "Amplify CLI", "description": "Official AWS Amplify Gen 1 CLI for provisioning auth, APIs, storage, functions, hosting, and environments for Amplify apps.", "long_description": "AWS Amplify CLI is the official Gen 1 command surface for creating and managing Amplify backends backed by CloudFormation. It covers project init, backend category changes, environment sync, codegen, and export workflows for existing Amplify Gen 1 apps.\n\n## What It Enables\n- Initialize or attach Amplify Gen 1 projects, add or update auth, APIs, storage, functions, hosting, and other backend categories, then push those changes into AWS.\n- Pull, list, inspect, import, and switch backend environments so teams can keep local state aligned with deployed Amplify environments.\n- Export Amplify-managed resources to a CDK app or regenerate frontend config and GraphQL code artifacts from the backend definition.\n\n## Agent Fit\n- Many workflows map to explicit shell commands and checked-in project files, and the CLI has real headless paths for CI-style init and category operations.\n- Structured output is limited: `amplify env list\/get --json` exists, but most commands return human-readable tables, status text, or filesystem side effects rather than rich JSON.\n- Best for agents already operating inside an existing Amplify Gen 1 repo with credentials in place; greenfield setup is more brittle because prompts, confirmations, and service-specific wizards still dominate much of the UX.\n\n## Caveats\n- This repo and CLI are for Amplify Gen 1; the README now recommends Amplify Gen 2 for new projects.\n- AWS credentials and some setup flows still rely on interactive configuration unless you supply the full headless arguments.", "category": "cloud", "install": "npm install -g @aws-amplify\/cli", "github": "https:\/\/github.com\/aws-amplify\/amplify-cli", "website": "https:\/\/docs.amplify.aws\/gen1\/", "source_url": "https:\/\/github.com\/aws-amplify\/amplify-cli", "stars": 2874, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "AWS" }, { "slug": "playerctl", "name": "playerctl", "description": "Linux media control CLI for inspecting and controlling MPRIS-enabled players over D-Bus.", "long_description": "playerctl is a Linux CLI for querying and controlling media players that expose the MPRIS interface on the session D-Bus. It gives the shell a simple way to drive playback and read track state from apps like VLC, mpv, browsers, or Spotify without scripting D-Bus directly.\n\n## What It Enables\n- Play, pause, stop, skip, seek, change volume, toggle shuffle or loop, and open URIs on the current player or a selected set of players.\n- Read status, position, and track metadata for status bars, notifications, or shell scripts, with custom output formatting.\n- Watch playback changes over time with follow mode and target the most recently active player through the bundled playerctld daemon.\n\n## Agent Fit\n- Commands are direct, non-interactive, and return failing exit codes when no player is found or a command cannot be handled.\n- Inspection output is plain text or custom-formatted strings only; there is no JSON mode, so downstream parsing is brittle.\n- Best for Linux desktop automation where an agent needs to drive an already running MPRIS-capable player rather than browse or manage a media service account.\n\n## Caveats\n- Requires a Linux session D-Bus and players that implement MPRIS; some apps need plugins or desktop-session environment fixes before they appear.\n- Scope is local playback control and metadata, not library search, playlists, or remote service management.", "category": "media", "install": "sudo dnf install playerctl", "github": "https:\/\/github.com\/altdesktop\/playerctl", "website": null, "source_url": "https:\/\/github.com\/altdesktop\/playerctl", "stars": 2866, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "diffsitter", "name": "diffsitter", "description": "AST-aware diff CLI that compares syntax trees instead of raw lines for source files.", "long_description": "diffsitter is a local semantic diff CLI that parses source files with tree-sitter and compares syntax trees instead of raw lines. It is aimed at code review and edit inspection where formatting noise would otherwise dominate a normal diff.\n\n## What It Enables\n- Compare two source files and surface structural code changes while ignoring whitespace-only or formatting-only churn.\n- Force a language, adjust node filtering and whitespace handling, and tune file associations so diffs follow the syntax that matters for a project.\n- Emit diff data as JSON or terminal output, then plug it into review scripts, `git difftool` flows, or post-edit verification steps.\n\n## Agent Fit\n- The interface is non-interactive by default: two file paths in, exit status and diff output out, with `--renderer json` available for follow-up parsing.\n- It fits local inspect loops well when an agent needs to compare generated code or review a patch semantically before handing results to a human.\n- Scope is narrower than tools like `git` or `ast-grep`: it only compares files, depends on supported tree-sitter grammars, and does not mutate repositories or services.\n\n## Caveats\n- The README explicitly says the project is still a work in progress and not yet production ready.\n- Unsupported file types require a configured fallback diff command, and language support is bounded by bundled or loadable tree-sitter grammars.", "category": "dev-tools", "install": "cargo install diffsitter --bin diffsitter", "github": "https:\/\/github.com\/afnanenayet\/diffsitter", "website": null, "source_url": "https:\/\/github.com\/afnanenayet\/diffsitter", "stars": 2339, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "choose", "name": "choose", "description": "Field and character selection CLI for slicing whitespace- or regex-separated text in shell pipelines.", "long_description": "choose is a small text-selection CLI for pulling fields or character ranges from each input line with slice-like syntax. It is built for quick shell pipeline work on whitespace-separated, delimiter-separated, or regex-split text.\n\n## What It Enables\n- Extract specific columns or ranges from command output, logs, and flat files without writing short `awk` programs.\n- Slice from the front or back of each line with open-ended ranges, negative indexes, and reverse ranges when you need tail fields or reordered spans.\n- Split on whitespace, literal delimiters, or regex separators, and switch to character-wise slicing for fixed-width text.\n\n## Agent Fit\n- Streams stdin or file input without prompts, so it composes cleanly in shell pipelines and inspect\/transform loops.\n- Output is plain text only, with no JSON or schema awareness, so downstream automation still depends on delimiters or additional parsing.\n- Best when an agent needs to reshape ad hoc line output from other CLIs; less compelling once the upstream tool already exposes structured data.\n\n## Caveats\n- Line-oriented only: it does not understand CSV quoting, headers, or nested structured formats.\n- Selection is its whole scope; filtering, aggregation, and richer transforms still belong to more expressive text or data processors.", "category": "file-management", "install": "brew install choose-rust", "github": "https:\/\/github.com\/theryangeary\/choose", "website": null, "source_url": null, "stars": 2197, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "ionic", "name": "Ionic CLI", "description": "Official Ionic CLI for scaffolding, serving, building, and running Ionic apps with Capacitor or Cordova.", "long_description": "Ionic CLI is the official command surface for creating and working on Ionic app projects. It covers project scaffolding, local dev servers, web builds, framework generators, native run flows, and Ionic Appflow-linked operations.\n\n## What It Enables\n- Scaffold new Ionic apps or initialize existing repos, then generate framework-specific pages, components, or features inside supported projects.\n- Serve and build Ionic web assets, then hand off to Capacitor or Cordova commands to run apps on iOS or Android devices or open native IDEs.\n- Link projects to Ionic Appflow, manage project config and integrations, and inspect local environment or account-related details from the terminal.\n\n## Agent Fit\n- Commands are explicit and backed by project files such as `ionic.config.json`, which makes inspect, change, and verify loops workable inside an existing repo.\n- JSON output is real but narrow, mostly on help, config, and inspection paths rather than the main `start`, `serve`, `build`, or native run workflows.\n- Best when an agent is already inside an Ionic project with Node, platform tooling, and credentials configured; greenfield setup still leans on prompts and browser login.\n\n## Caveats\n- Many high-value commands depend on local mobile SDKs, emulators, browsers, or a connected device, so unattended runs are environment-sensitive.\n- Appflow-linked features such as login, project linking, and SSH key management require account auth and can fall back to interactive confirmation unless preconfigured.", "category": "dev-tools", "install": "npm install -g @ionic\/cli", "github": "https:\/\/github.com\/ionic-team\/ionic-cli", "website": "https:\/\/ionicframework.com\/docs\/cli", "source_url": "https:\/\/ionicframework.com\/docs\/cli", "stars": 2004, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Ionic" }, { "slug": "crictl", "name": "crictl", "description": "Node-level CLI for inspecting and manipulating CRI containers, images, pod sandboxes, and runtime state on Kubernetes nodes.", "long_description": "crictl is the Kubernetes CRI CLI for talking directly to a container runtime on a node without going through the Kubernetes API. It is mainly a debugging and runtime-operations tool for containerd, CRI-O, and other CRI-compatible runtimes.\n\n## What It Enables\n- List and inspect pod sandboxes, containers, images, logs, runtime info, filesystem info, stats, metrics, and event streams directly from the CRI socket.\n- Create, start, stop, update, checkpoint, and remove pod sandboxes or containers, pull and prune images, and adjust runtime settings during node-level debugging.\n- Exec into containers, attach, and port-forward when troubleshooting workloads from the runtime side rather than the Kubernetes API side.\n\n## Agent Fit\n- Many read paths are machine-readable: `info`, `inspect`, `inspectp`, `inspecti`, `ps`, `pods`, `images`, `stats`, `statsp`, `metricsp`, `metricdescs`, and `events` support JSON or YAML output, with go-template support on several inspect and status commands.\n- Commands are direct shell verbs with filters, flags, and stable exit behavior, so they fit inspect, change, and verify loops for node diagnostics and runtime-focused automation.\n- Fit is narrower than cluster-facing tooling because it requires direct access to the CRI endpoint on a node, and some useful flows like `exec`, `attach`, `logs -f`, `events`, and `port-forward` are streaming or interactive rather than batch-friendly.\n\n## Caveats\n- It is only useful where you can reach the CRI socket on a node; this is not a remote Kubernetes API client.\n- Upstream docs warn that pods or containers created directly with `crictl` may be removed by kubelet if they do not exist in the Kubernetes API.", "category": "containers", "install": "brew install cri-tools", "github": "https:\/\/github.com\/kubernetes-sigs\/cri-tools", "website": null, "source_url": "https:\/\/github.com\/kubernetes-sigs\/cri-tools", "stars": 1952, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Kubernetes" }, { "slug": "stripe", "name": "Stripe CLI", "description": "Official Stripe CLI for webhook testing, API requests, request logs, and local integration workflows.", "long_description": "Stripe CLI is Stripe's official command line for local integration development, webhook testing, direct API requests, and request-log inspection. It combines generic API access with Stripe-specific helpers for common test and debugging loops.\n\n## What It Enables\n- Forward Stripe webhooks to a local server, print signing secrets, and trigger or resend test events while developing integrations.\n- Create, retrieve, update, and delete Stripe resources from the shell across a large generated command tree, or fall back to generic `get`, `post`, and `delete` requests.\n- Tail live API request logs, inspect webhook traffic, and use fixtures or sample commands to reproduce integration scenarios faster.\n\n## Agent Fit\n- Resource commands return JSON responses, and streaming commands like `listen --format JSON` and `logs tail --format JSON` are straightforward to parse in follow-up shell steps.\n- The command surface maps well to inspect, change, and verify loops, but unattended use depends on API keys or existing login state, and some flows open a browser or prompt before destructive actions.\n- Best fit for agents working inside Stripe development or support workflows, especially sandbox testing, webhook debugging, and targeted API operations.\n\n## Caveats\n- Initial auth is browser-based by default with `stripe login`, though `--api-key` and an interactive fallback exist for non-browser setups.\n- Some commands are long-running local development loops or safety-gated mutations, so they need extra orchestration in CI or unattended agent runs.", "category": "utilities", "install": "brew install stripe\/stripe-cli\/stripe", "github": "https:\/\/github.com\/stripe\/stripe-cli", "website": "https:\/\/docs.stripe.com\/stripe-cli", "source_url": "https:\/\/docs.stripe.com\/stripe-cli", "stars": 1880, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "stripe", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Stripe" }, { "slug": "netlify", "name": "Netlify CLI", "description": "Official Netlify CLI for deploying sites, running local dev, and managing Netlify projects, env vars, functions, and logs.", "long_description": "Netlify CLI is the official command surface for deploying and operating Netlify sites from a repo, local shell, or CI job. It covers deploys, local dev emulation, environment variables, logs, site management, functions, and raw Netlify API calls.\n\n## What It Enables\n- Deploy static sites, serverless functions, and edge functions as draft or production builds, including site creation and build triggers.\n- Run local Netlify dev with redirects, deploy-context env vars, and function simulation, then invoke or serve functions for testing.\n- Inspect and change Netlify state from the shell: list sites, manage env vars, stream logs, call Open API methods, and manage Netlify agent tasks.\n\n## Agent Fit\n- Several high-value commands expose `--json`, including deploy, site listing, status, env management, functions listing, and agent task inspection.\n- The command surface fits inspect\/change\/verify loops well in CI or local automation when the repo is already linked to a Netlify project.\n- Browser login, project linking, and some fallback prompts mean unattended runs work best with explicit flags and a preset `NETLIFY_AUTH_TOKEN`.\n\n## Caveats\n- JSON output is command-specific rather than universal, so some flows still return human-oriented logs or interactive prompts.\n- A lot of the value assumes an existing Netlify project or repo context; greenfield setup is less smooth for headless agents.", "category": "cloud", "install": "npm install netlify-cli -g", "github": "https:\/\/github.com\/netlify\/cli", "website": "https:\/\/cli.netlify.com\/", "source_url": null, "stars": 1812, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "netlify", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Netlify" }, { "slug": "bw", "name": "Bitwarden CLI", "description": "Official Bitwarden CLI for vault login, credential retrieval, item management, and Bitwarden Send from the terminal.", "long_description": "Bitwarden CLI is Bitwarden's command line for working with personal or organization vault data from the shell. It covers login and unlock flows, credential retrieval, item management, imports and exports, password generation, Bitwarden Send, and an optional local API mode.\n\n## What It Enables\n- Log in, unlock, sync, and query vault items, then retrieve usernames, passwords, notes, attachments, exposed-password checks, and TOTP codes.\n- Create, edit, archive, restore, delete, import, and export items, folders, org collections, and related vault data without opening the web app.\n- Generate passwords or passphrases, create or receive Bitwarden Sends, and optionally expose the same operations through the local `bw serve` REST API.\n\n## Agent Fit\n- Most inspect and mutate commands are non-TUI and stdout-oriented, and list, object, and template outputs are JSON by default; `--response` returns a full JSON response envelope when you need status metadata too.\n- It works well for credential retrieval and vault automation once auth is established, especially when a skill standardizes item names, org IDs, and server configuration.\n- Automation gets weaker around login and unlock: SSO can open a browser, 2FA and new-device verification may prompt, and locked-vault flows require a valid `BW_SESSION` or interactive unlock.\n\n## Caveats\n- Requires a Bitwarden account plus an authenticated, synced, unlocked vault for most useful commands.\n- Bitwarden's current README says the Homebrew build is not recommended for all users because it omits device approval commands for some Enterprise SSO flows.", "category": "security", "install": "npm install -g @bitwarden\/cli", "github": "https:\/\/github.com\/bitwarden\/cli", "website": "https:\/\/bitwarden.com\/help\/cli\/", "source_url": "https:\/\/bitwarden.com\/help\/cli\/", "stars": 1673, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Bitwarden" }, { "slug": "flyctl", "name": "flyctl", "description": "Official Fly.io CLI for launching, deploying, scaling, and operating apps and machines on Fly.io.", "long_description": "flyctl is Fly.io's official CLI for creating, deploying, and operating apps, Machines, networking, storage, and managed services on the Fly.io platform. It spans first deploy setup from local source through day-2 operations like scaling, logs, secrets, certificates, and machine lifecycle control.\n\n## What It Enables\n- Launch new Fly.io apps from local source or a template repo, generate app config, provision attached services, and perform first deploys.\n- Inspect and operate running apps with app lists, machine status, releases, logs, secrets, certificates, IPs, volumes, and organization-level controls.\n- Change platform state directly from the shell by deploying new versions, scaling VM or count settings, restarting or cloning Machines, and managing attached storage.\n\n## Agent Fit\n- Repeated `--json` support across app, machine, status, log, secret, certificate, org, volume, and other resource commands, plus local `fly.toml` discovery, make inspect, change, and verify loops practical.\n- Once auth and app context are in place, most operational commands are stable shell primitives, but `auth login`, `launch`, and watch or streaming flows still introduce browser, prompt, or live-session friction.\n- Can also expose a built-in MCP server and proxy when a team wants that integration model.\n\n## Caveats\n- You need a Fly.io account and auth context, and many commands assume either `-a` or a local `fly.toml` to resolve the target app.\n- Bootstrap paths like `launch` are more interactive than steady-state operations, so unattended automation is strongest after the app and config already exist.", "category": "cloud", "install": "brew install flyctl", "github": "https:\/\/github.com\/superfly\/flyctl", "website": "https:\/\/fly.io\/docs\/flyctl\/", "source_url": null, "stars": 1621, "language": "Go", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Fly.io" }, { "slug": "supabase", "name": "Supabase CLI", "description": "Official Supabase CLI for local stacks, database migrations, Edge Functions, and project management.", "long_description": "Supabase CLI is Supabase's official command line for local development and hosted project operations. It combines local stack control, database and Edge Function workflows, and management API actions in one tool.\n\n## What It Enables\n- Start a full local Supabase stack, inspect service URLs and local keys, and link a working directory to a remote Supabase project.\n- Diff, pull, push, dump, lint, and reset Postgres schema changes; generate typed clients from the database schema; and create, serve, deploy, or download Edge Functions.\n- Create or inspect projects and preview branches, list API keys, manage secrets, restore backups, and handle other project-level operations without using the dashboard.\n\n## Agent Fit\n- One CLI covers local inspect, change, and verify loops plus hosted management tasks, which is useful when an agent needs to move between repo-local work and remote Supabase state.\n- The shared `-o` output encoder gives many status, list, and get-style commands real JSON, YAML, TOML, or env output, but DB migrations, dumps, and some codegen flows still write text or files instead of structured results.\n- Automation works best with explicit flags, linked project refs, and `SUPABASE_ACCESS_TOKEN`; login and some create, delete, or selection flows can prompt, and the local stack can also expose an `\/mcp` endpoint when Studio is enabled.\n\n## Caveats\n- Local development commands depend on Docker containers and a Supabase project config in the working directory.\n- Management API commands require auth up front, and several commands fall back to interactive prompts if IDs, refs, or passwords are omitted.", "category": "databases", "install": "brew install supabase\/tap\/supabase", "github": "https:\/\/github.com\/supabase\/cli", "website": "https:\/\/supabase.com\/docs\/reference\/cli", "source_url": null, "stars": 1607, "language": "Go", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": "supabase", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Supabase" }, { "slug": "travis", "name": "Travis CI CLI", "description": "Travis CI CLI for inspecting builds, streaming logs, managing repo settings and env vars, and encrypting `.travis.yml` secrets.", "long_description": "Travis CI CLI is the shell client for working with Travis CI repositories, builds, and configuration. It covers build inspection, log access, repository-level settings and secrets, and `.travis.yml` setup tasks, with a direct API escape hatch through `raw` when needed.\n\n## What It Enables\n- Check build status, history, requests, branches, and logs for a Travis project, then follow failures or open the related build page for more detail.\n- Enable or disable repositories, restart or cancel builds, sync repos from GitHub, and manage repository env vars, settings, caches, and SSH keys.\n- Encrypt values or files for `.travis.yml`, lint or scaffold Travis config, and add supported deploy or addon sections without editing YAML by hand.\n\n## Agent Fit\n- Repo-scoped commands plus flags like `--repo`, `--token`, and `status --exit-code` make it workable in scripted inspect-change-verify loops around Travis CI state.\n- Structured output is limited. Real JSON support is mainly `raw --json`, while most other commands print human-oriented text, color, or streaming logs.\n- Best for Travis-specific automation on known repositories; login, repo autodetection, and some setup paths still assume an interactive shell.\n\n## Caveats\n- Parts of the command surface reflect older Travis CI eras, including `travis-ci.org` references, deprecated endpoint shortcuts, and many aging deploy target helpers.\n- The checked-in README install guidance lags the current gemspec, so runtime requirements in docs are less trustworthy than the package metadata.", "category": "dev-tools", "install": "gem install travis", "github": "https:\/\/github.com\/travis-ci\/travis.rb", "website": null, "source_url": "https:\/\/github.com\/travis-ci\/travis.rb", "stars": 1589, "language": "Ruby", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Travis CI" }, { "slug": "hcloud", "name": "Hetzner Cloud CLI", "description": "Official Hetzner Cloud CLI for managing servers, networking, load balancers, storage, and DNS from the shell.", "long_description": "hcloud is Hetzner's official CLI for provisioning and operating Hetzner Cloud resources, plus related Hetzner services like Storage Boxes and DNS zones. It covers both inventory-style inspection and day-2 changes such as server lifecycle, networking, volumes, firewalls, and load balancer operations.\n\n## What It Enables\n- Create, inspect, update, and delete servers, volumes, networks, floating IPs, firewalls, load balancers, placement groups, certificates, and SSH keys from one CLI.\n- Handle day-2 infrastructure work such as power actions, rebuilds, rescue mode, reverse DNS, backups, metrics, and network or firewall attachments.\n- Manage related Hetzner services including Storage Boxes, subaccounts, snapshots, DNS zones, and RRsets without dropping to raw API calls.\n\n## Agent Fit\n- Repeated `--output json` and `--output yaml` support across create, list, and describe commands makes inspect, change, and verify loops easy to script and parse.\n- Most resource operations are explicit non-interactive Cobra commands with stable flags, so they compose well in shell automation once auth context is already configured.\n- Bootstrap and helper paths are less uniform: `context create` prompts for credentials by default, and commands like `server ssh` hand off to another interactive program instead of staying fully machine-oriented.\n\n## Caveats\n- You need a Hetzner API token and local context before most commands are useful; unattended setup works best with `--token-from-env`.\n- Not every command exposes the same structured output surface, and experimental features can change within minor releases.", "category": "cloud", "install": "brew install hcloud", "github": "https:\/\/github.com\/hetznercloud\/cli", "website": null, "source_url": "https:\/\/github.com\/hetznercloud\/cli", "stars": 1539, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Hetzner Cloud" }, { "slug": "figma-code-connect", "name": "Figma Code Connect", "description": "Official Figma CLI for generating, parsing, and publishing Code Connect mappings between code components and Figma components.", "long_description": "Figma Code Connect is Figma's CLI for linking code components in a design system to Figma components so Dev Mode can show production snippets instead of autogenerated examples. It also handles the local parsing, publishing, unpublishing, and migration steps behind those mappings.\n\n## What It Enables\n- Generate starter Code Connect files from a Figma node URL and detect the right parser or config for React, HTML, SwiftUI, Jetpack Compose, or custom setups.\n- Parse local Code Connect files into JSON, validate them against Figma, and publish or unpublish mappings so Dev Mode reflects the code your team actually ships.\n- Migrate parser-based mappings to parserless `.figma.js` templates and keep component, source, and label metadata tied back to your repo.\n\n## Agent Fit\n- Works reasonably in scripted repo workflows because commands are explicit, config-driven, and `figma connect parse` produces machine-readable JSON for follow-up checks.\n- Automation fit is mixed: the default `figma connect` entrypoint launches an interactive wizard with prompts, and mutating commands require Figma API access plus project-specific source layout.\n- Best for agents maintaining an existing design-system handoff pipeline, not for broad Figma automation or general design editing from the shell.\n\n## Caveats\n- Code Connect is limited to Figma Organization and Enterprise plans and requires a full Design or Dev Mode seat.\n- The scope is narrow by design: it links code components to Figma Dev Mode rather than exposing the broader Figma product as a general-purpose CLI control plane.", "category": "dev-tools", "install": "npm install -g @figma\/code-connect", "github": "https:\/\/github.com\/figma\/code-connect", "website": "https:\/\/developers.figma.com\/docs\/code-connect\/", "source_url": "https:\/\/www.figma.com\/developers\/code-connect", "stars": 1400, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "vendor", "vendor_name": "Figma" }, { "slug": "trash-cli", "name": "trash-cli", "description": "Safe-delete CLI for moving files and folders to the system trash instead of removing them permanently.", "long_description": "trash-cli is a small cross-platform CLI that moves files and folders to the system trash instead of removing them permanently. It covers one narrow job, but that job matters in shell workflows where agents or scripts need a safer alternative to `rm`.\n\n## What It Enables\n- Trash files, folders, and quoted glob matches from scripts without bypassing the OS recycle or trash mechanism.\n- Replace risky cleanup steps with a reversible delete primitive for generated files, temp assets, or other local content.\n- Print trashed paths with `--verbose` when a script needs a minimal audit trail of what was moved.\n\n## Agent Fit\n- Path-based arguments, straightforward flags, and non-interactive execution make it easy to drop into cleanup scripts and agent loops.\n- The automation surface is intentionally small: there is no JSON output, no built-in list or restore command, and no broader filesystem inspection features.\n- Best used as a safety layer around destructive local file operations when human recovery from mistakes still matters.\n\n## Caveats\n- It ignores common `rm` flags for compatibility, but it does not implement full `rm` semantics or richer file-management workflows.\n- Glob patterns should be quoted, and dotfiles require `--dot` to be matched.", "category": "file-management", "install": "npm install -g trash-cli", "github": "https:\/\/github.com\/sindresorhus\/trash-cli", "website": null, "source_url": null, "stars": 1388, "language": "JavaScript", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "opam", "name": "opam", "description": "OCaml package manager CLI for compiler switches, packages, pins, and reproducible language environments.", "long_description": "OCaml package manager CLI for compiler switches, packages, pins, and reproducible language environments.\n\n## Highlights\n- Installs with `brew install opam`\n- Primary implementation language is OCaml\n- Maintained by the upstream opam team\n\n## Agent Fit\n- Fits shell scripts and agent workflows that need a terminal-native interface\n- Straightforward installation helps bootstrap local or ephemeral automation environments", "category": "package-managers", "install": "brew install opam", "github": "https:\/\/github.com\/ocaml\/opam", "website": "https:\/\/opam.ocaml.org", "source_url": "https:\/\/opam.ocaml.org", "stars": 1339, "language": "OCaml", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "opam" }, { "slug": "cf-terraforming", "name": "cf-terraforming", "description": "Cloudflare CLI for generating Terraform configuration and import commands from existing account and zone resources.", "long_description": "cf-terraforming is Cloudflare's bootstrap CLI for turning existing account or zone resources into Terraform configuration and matching import commands. It is aimed at Terraform adoption and migration work, not day-to-day Cloudflare operations.\n\n## What It Enables\n- Export existing Cloudflare resources into Terraform HCL for selected account-level or zone-level resource types.\n- Generate matching `terraform import` commands or Terraform 1.5 import blocks so existing resources can be brought into state.\n- Migrate parts of an existing Cloudflare setup into Terraform incrementally instead of rewriting resources by hand.\n\n## Agent Fit\n- Useful when an agent needs a one-time snapshot of existing Cloudflare state and a starting Terraform representation to work from.\n- Output is HCL and plain-text import commands rather than JSON, so follow-up automation is less direct than with inspection-first service CLIs.\n- Flags and environment-variable auth support headless runs, but it depends on an initialized Terraform working directory and the README says it is not intended for CI.\n\n## Caveats\n- Requires Cloudflare credentials plus a prepared Terraform directory with the Cloudflare provider available.\n- Coverage depends on supported resource mappings, and some resources need explicit `--resource-id` values to generate or import correctly.", "category": "networking", "install": "brew install cloudflare\/cloudflare\/cf-terraforming", "github": "https:\/\/github.com\/cloudflare\/cf-terraforming", "website": null, "source_url": "https:\/\/github.com\/cloudflare\/cf-terraforming", "stars": 1325, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Cloudflare" }, { "slug": "fping", "name": "fping", "description": "Parallel ICMP ping CLI for host discovery, reachability checks, subnet sweeps, and latency measurement.", "long_description": "fping is a parallel ICMP probing tool for checking many hosts in one run. It focuses on fast reachability and timing measurements rather than the single-target, human-oriented flow of `ping`.\n\n## What It Enables\n- Sweep CIDR ranges or explicit host lists to find which addresses respond, which time out, and which names fail to resolve.\n- Measure packet loss, min or avg or max RTT, outage time, and interval summaries across many hosts for monitoring or network-change verification.\n- Run repeatable reachability checks in scripts, CI, or incident workflows with count, loop, quiet, stats, and file-driven target modes.\n\n## Agent Fit\n- The CLI is built for non-interactive batch use, so it fits inspect and verify loops where an agent needs a quick answer about network reachability.\n- Structured output is real and useful: `--json` emits newline-delimited event and summary objects that are easy to parse in follow-up shell steps.\n- Fit is narrower than a cloud or service CLI because it only inspects network path health; it does not change remote state and JSON output is limited to count or loop-style modes.\n\n## Caveats\n- Raw ICMP access may require root, `setcap`, or Linux ping-group configuration depending on the platform and how `fping` was installed.\n- The checked-in JSON docs label the format alpha, so field names and object types should be treated as version-sensitive.", "category": "networking", "install": "brew install fping", "github": "https:\/\/github.com\/schweikert\/fping", "website": "https:\/\/fping.org", "source_url": "https:\/\/fping.org", "stars": 1181, "language": "C", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "sentry", "name": "Sentry CLI", "description": "Official Sentry CLI for releases, source maps, debug files, logs, issues, and cron monitors.", "long_description": "Sentry CLI is Sentry's official command-line client for release management, artifact uploads, and selected project operations. It is mainly the automation layer behind source map and debug-symbol handling, release bookkeeping, build uploads, issue or log inspection, and cron monitor check-ins.\n\n## What It Enables\n- Create, finalize, archive, restore, and inspect Sentry releases, attach commits, and record deploys from CI.\n- Upload or inspect source maps, debug symbols, ProGuard mappings, Dart symbol maps, and app builds so Sentry can symbolicate crashes and link artifacts to releases.\n- List issues, events, logs, projects, repos, or organizations, and wrap scheduled jobs with cron monitor check-ins that track the child command's success or failure.\n\n## Agent Fit\n- Release, sourcemap, debug-file, build, and monitor commands are non-interactive and map cleanly onto CI or scripted remediation loops.\n- Selected commands expose JSON output, especially for config checks and debug-file inspection, which helps with environment validation and artifact triage.\n- Read workflows are less clean for agents because many list commands default to human tables instead of structured output.\n\n## Caveats\n- Unattended use assumes an auth token is already configured, because the login flow can open a browser and prompt for input.\n- Some features are deployment-dependent: `build upload` is SaaS-only, and newer CLI versions require recent self-hosted Sentry releases.", "category": "dev-tools", "install": "curl -sL https:\/\/sentry.io\/get-cli\/ | sh", "github": "https:\/\/github.com\/getsentry\/sentry-cli", "website": "https:\/\/docs.sentry.io\/cli\/", "source_url": null, "stars": 986, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "sentry", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Sentry" }, { "slug": "sentry-cli", "name": "Sentry CLI", "description": "Official Sentry CLI for releases, deploys, sourcemaps, debug files, issue and log inspection, and cron monitor check-ins.", "long_description": "Sentry CLI is Sentry's command-line tool for release management, build artifact uploads, manual event sending, log inspection, and cron monitor check-ins. It is most useful in CI or scripted delivery flows that need to talk to Sentry without opening the web app.\n\n## What It Enables\n- Create, finalize, archive, delete, and inspect releases, then attach deploy records and commit metadata from local git or configured repositories.\n- Upload sourcemaps, debug symbols, source bundles, ProGuard mappings, and mobile build artifacts so Sentry can symbolicate errors and releases correctly.\n- List issues, events, logs, projects, repos, and monitors; send manual events; and wrap scheduled jobs so Sentry records monitor check-ins.\n\n## Agent Fit\n- Works well in CI when org or project defaults and auth tokens are supplied non-interactively; `monitors run` is especially shell-friendly because it wraps a command and exits with that command's status.\n- There is real structured output, but it is uneven: `debug-files check`, `debug-files find`, and `info --config-status-json` emit JSON, while many inspect commands print tables and `releases list` only offers raw text.\n- Browser-assisted `login` and Sentry's separate newer interactive CLI make this a better fit for release and artifact automation than for broad day-to-day incident triage by agents.\n\n## Caveats\n- Useful unattended use assumes auth tokens and org or project context are already configured.\n- Official docs now point users seeking the newer interactive human or agent CLI to `cli.sentry.dev`, so `sentry-cli` should be positioned here as the build and release automation tool.", "category": "system-monitoring", "install": "curl -sL https:\/\/sentry.io\/get-cli\/ | sh", "github": "https:\/\/github.com\/getsentry\/sentry-cli", "website": "https:\/\/docs.sentry.io\/cli\/", "source_url": "https:\/\/docs.sentry.io\/cli\/", "stars": 986, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Sentry" }, { "slug": "sox", "name": "SoX", "description": "Audio processing CLI for converting files, applying effects, recording or playing audio, and inspecting audio metadata.", "long_description": "SoX is a general-purpose audio processing CLI for file conversion, effect chains, playback, recording, and basic analysis. It fits batch media workflows where you need direct shell control over audio files or streams.\n\n## What It Enables\n- Convert between many audio formats and audio devices, including piping audio through stdin or stdout inside larger shell workflows.\n- Apply edit and mastering operations such as trim, mix, resample, normalize, noise reduction, tempo or pitch changes, and silence-based splitting.\n- Inspect audio headers with `soxi` and generate analysis outputs such as level statistics, frequency stats, and spectrogram PNGs.\n\n## Agent Fit\n- Commands are non-interactive by default and compose well in shell pipelines, which makes SoX useful for repeatable transcode, cleanup, and batch-processing jobs.\n- `soxi` can emit single values for scripts, but SoX does not offer structured JSON output and several analysis commands write human-oriented text to stderr.\n- Best when an agent needs to transform or inspect audio files directly; weaker for workflows that need richer media semantics than file-level operations provide.\n\n## Caveats\n- Supported formats and device features depend on how SoX was compiled and which optional codec libraries are installed.\n- Many operations read or write binary audio data or files, so verification often depends on follow-up metadata checks or listening or media-specific tests rather than text diffs.", "category": "media", "install": "brew install sox", "github": "https:\/\/github.com\/chirlu\/sox", "website": "https:\/\/sourceforge.net\/projects\/sox\/", "source_url": null, "stars": 884, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "heroku", "name": "Heroku CLI", "description": "Official Heroku CLI for apps, releases, add-ons, logs, pipelines, and platform operations from the terminal.", "long_description": "Heroku CLI is Heroku's official control surface for deploying and operating apps, add-ons, pipelines, data services, and account resources from the shell. It covers both first deploy setup and day-2 tasks like config changes, releases, logs, database maintenance, and one-off dyno commands.\n\n## What It Enables\n- Create and configure Heroku apps, attach add-ons, deploy container or git-based workloads, and run one-off dyno commands without leaving the terminal.\n- Inspect and operate live apps with releases, logs, errors, domains, certs, spaces, pipelines, review apps, and team or access controls.\n- Manage Heroku Postgres and Redis resources with backups, credentials, maintenance actions, diagnostics, and other data-service operations.\n\n## Agent Fit\n- Many resource and info commands expose `--json`, which works well for inspect, parse, and follow-up mutation loops.\n- Once auth and app context are in place, the CLI is broad enough to handle most Heroku day-2 operations directly, but logs and some workflows remain plain-text or streaming rather than structured.\n- Browser login by default and confirmation-gated destructive actions add friction for unattended bootstrap or mutation flows, though MCP support is available when a team wants that integration model.\n\n## Caveats\n- You need a Heroku account and auth context, and many commands expect `--app` or a git remote to resolve the target app.\n- Some high-value workflows are still interactive or text-heavy, especially browser-based login, streaming logs, and destructive commands that require explicit confirmation.", "category": "cloud", "install": "brew install heroku\/brew\/heroku", "github": "https:\/\/github.com\/heroku\/cli", "website": "https:\/\/devcenter.heroku.com\/articles\/heroku-cli", "source_url": "https:\/\/devcenter.heroku.com\/articles\/heroku-cli", "stars": 877, "language": "TypeScript", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Heroku" }, { "slug": "imsg", "name": "imsg", "description": "macOS Messages CLI for listing chats, reading history, watching new messages, and sending iMessage or SMS.", "long_description": "imsg is a macOS CLI for Apple Messages that reads the local chat database and sends through Messages.app. It covers inbox inspection, live message streaming, and outbound texting from the shell.\n\n## What It Enables\n- List recent chats, inspect message history, and filter messages by participants or time range.\n- Stream new messages, attachments, and optional tapback reaction events as JSON lines for automations.\n- Send texts, files, and tapback reactions to direct or group chats, or keep a stdio JSON-RPC process open for longer-lived workflows.\n\n## Agent Fit\n- `--json` output is implemented across the main read paths plus send and react acknowledgements, so agents can parse chats, messages, and event streams without scraping text.\n- `imsg rpc` exposes chats, history, watch subscriptions, and send over JSON-RPC 2.0 on stdin\/stdout, which fits subprocess-based agent loops well.\n- Fit is local-Mac only: it depends on Messages.app state and macOS permissions, and reaction sending uses UI automation rather than a fully headless API.\n\n## Caveats\n- Requires macOS 14+, Messages signed in, and Full Disk Access to read `~\/Library\/Messages\/chat.db`.\n- Sending needs Automation permission, SMS relay is optional for SMS, and `react` also depends on UI automation with Messages.app running.", "category": "utilities", "install": "make build", "github": "https:\/\/github.com\/steipete\/imsg", "website": null, "source_url": null, "stars": 820, "language": "Swift", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "apple", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "httpyac", "name": "httpyac", "description": "API request runner for `.http` and `.rest` files across HTTP, GraphQL, gRPC, WebSocket, MQTT, and OAuth2 workflows.", "long_description": "httpyac is a request runner for `.http` and `.rest` files, aimed at API workflows that are easier to keep in text than in a GUI client. It can execute single requests or whole collections across HTTP and several adjacent protocols.\n\n## What It Enables\n- Run named, tagged, line-selected, or whole-file request suites from checked-in `.http` and `.rest` files.\n- Apply environments, inline variables, dotenv-backed config, and OAuth2 token generation to repeatable API calls across HTTP, GraphQL, gRPC, WebSocket, MQTT, and related protocols.\n- Execute assertions and export JSON or JUnit results for CI checks, regression tests, or agent follow-up steps.\n\n## Agent Fit\n- `--json` gives structured per-request summaries, responses, timestamps, durations, and test results that are straightforward to parse in shell loops.\n- Non-interactive usage is solid when you pass files plus `--all`, `--name`, `--line`, or `--tag`; otherwise `send` falls back to an interactive selector.\n- Best fit for repo-backed API workflows where request definitions live beside code and need inspect, change, and verify cycles.\n\n## Caveats\n- If you do not specify which request to run, the default selection path prompts through `inquirer`, which is awkward for unattended runs.\n- Most of the value assumes you maintain request files and environment data in the project rather than issuing one-off ad hoc commands.", "category": "http-apis", "install": "npm install -g httpyac", "github": "https:\/\/github.com\/AnWeber\/httpyac", "website": "https:\/\/httpyac.github.io\/", "source_url": "https:\/\/httpyac.github.io\/", "stars": 781, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "markdownlint-cli2", "name": "markdownlint-cli2", "description": "Markdown linting and auto-fix CLI for CommonMark files, docs repos, and content pipelines.", "long_description": "markdownlint-cli2 lints Markdown and CommonMark files across repos using directory-based configuration and the `markdownlint` rule set. It is built for docs checks, editor formatting flows, and CI runs where you want to find or automatically fix Markdown style issues.\n\n## What It Enables\n- Lint Markdown files across a repo with glob patterns, nested config files, ignore rules, and custom rule or parser configuration.\n- Auto-fix supported issues in place with `--fix`, or format Markdown from stdin to stdout with `--format` for editor and pipeline workflows.\n- Emit machine-readable findings through configured formatter packages such as JSON, JUnit, SARIF, GitLab Code Quality, or summary reports.\n\n## Agent Fit\n- Non-interactive runs and clear `0`\/`1`\/`2` exit codes make inspect-edit-rerun verification loops straightforward.\n- Repo-level config discovery and `--fix` support make it useful for documentation cleanup, pre-commit checks, and CI enforcement.\n- Structured output exists, but not as a one-off `--json` flag; unattended setups need an `outputFormatters` config entry such as `markdownlint-cli2-formatter-json`.\n\n## Caveats\n- JSON and other report formats are configured through formatter modules, so automation usually needs a checked-in config file instead of an ad hoc flag.\n- Auto-fix only covers rules that emit fix information, so some findings still need manual or agent-authored edits.", "category": "dev-tools", "install": "npm install markdownlint-cli2 --global", "github": "https:\/\/github.com\/DavidAnson\/markdownlint-cli2", "website": null, "source_url": "https:\/\/github.com\/DavidAnson\/markdownlint-cli2", "stars": 719, "language": "JavaScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "twitch-cli", "name": "Twitch CLI", "description": "Official Twitch CLI for Helix API calls, token workflows, EventSub simulation, and local mock Twitch testing.", "long_description": "Twitch CLI is Twitch's official developer command line for working against Helix APIs, generating tokens, and testing Twitch integrations locally. It is aimed at extension, bot, and backend developers who need a shell-level way to hit Twitch endpoints or simulate Twitch behavior.\n\n## What It Enables\n- Call Helix endpoints from the terminal with stored client credentials, query params, request bodies, verbose headers, and optional autopagination.\n- Generate, validate, refresh, and revoke app or user access tokens for local development and scripted integration checks.\n- Emit mock EventSub webhook or WebSocket events and run a local mock API server to test Twitch-connected apps without relying on production traffic.\n\n## Agent Fit\n- `twitch api` can return raw JSON and uses non-zero exit codes for non-2xx responses, which fits inspect, retry, and verification loops.\n- `twitch event trigger` prints generated payload JSON directly, so agents can create fixtures or forward test events without writing their own generators.\n- Best for agents exercising Twitch developer workflows in dev or CI-like environments; it is a narrower fit for general Twitch account management because auth and setup still involve prompts or browser-mediated login.\n\n## Caveats\n- Token and API commands depend on a Twitch developer app with a client ID and secret, and user-token flows usually require browser or device-code interaction.\n- Structured output is uneven across the CLI, and the mock API docs note that some surfaces such as EventSub and extensions are not fully covered by the local mock server.", "category": "http-apis", "install": "brew install twitchdev\/twitch\/twitch-cli", "github": "https:\/\/github.com\/twitchdev\/twitch-cli", "website": "https:\/\/dev.twitch.tv\/docs\/cli\/", "source_url": "https:\/\/github.com\/twitchdev\/twitch-cli", "stars": 665, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Twitch" }, { "slug": "1password", "name": "1Password CLI", "description": "Official CLI for accessing 1Password items, vaults, and secret references from the terminal. It also injects secrets into files, environment variables, and shell plugin auth flows.", "long_description": "1Password CLI brings 1Password to your terminal for secret references, item and vault management, and shell-plugin based CLI authentication. It supports direct reads, file templating, environment injection, and administrative automation across 1Password accounts.\n\n## Highlights\n- Read secret references with `op read`, or inject them into files and processes with `op inject` and `op run`.\n- Manage vault items, users, groups, service accounts, and related account resources from one CLI.\n- Configure shell plugins so third-party CLIs can pull credentials from 1Password with biometric or system authentication.\n\n## Agent Fit\n- Global `--format json` output and stdin-friendly commands make it easy to inspect results and pipe objects between commands.\n- Separate verbs for reads, item CRUD, and plugin inspection reduce ambiguity when automating changes or audits.\n- Composes cleanly with shell scripts and env-file workflows through `op run`, `op inject`, and `op plugin inspect`.\n\n## Caveats\n- Most real usage requires a signed-in 1Password account, app integration, or a service account.", "category": "security", "install": "brew install 1password-cli", "github": null, "website": "https:\/\/developer.1password.com\/docs\/cli", "source_url": null, "stars": 647, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "1password", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "1Password" }, { "slug": "planetscale", "name": "PlanetScale CLI", "description": "CLI for managing PlanetScale databases, branches, deploy requests, backups, and secure local connections.", "long_description": "PlanetScale CLI is the shell interface for managing PlanetScale databases, branches, deploy requests, and access credentials. It also exposes raw API calls and secure local connection flows for database work that would otherwise require the web console.\n\n## What It Enables\n- Create, inspect, delete, back up, dump, and restore databases and branches, then diff schemas, refresh branch metadata, or manage safe migration settings.\n- Review and deploy schema changes with deploy requests, or run Vitess workflow and keyspace operations for traffic switching and data verification.\n- Open secure local connections or shells to supported branches, create branch passwords or Postgres roles, and use `pscale api` for authenticated calls not covered by first-class commands.\n\n## Agent Fit\n- Global `--format human|json|csv` support and JSON-backed resource printers make most inspect and mutation commands straightforward to parse in scripts.\n- The command set supports real inspect, change, and verify loops because you can list resources, mutate them, then re-query state or drop to the raw API without changing auth context.\n- Unattended runs should avoid browser login, branch selection prompts, and confirmation gates by using tokens, explicit `--org` and resource arguments, and `--force` where required.\n\n## Caveats\n- Command coverage depends on database kind: deploy requests, workflows, connect, and several keyspace operations are Vitess-only, while role management is Postgres-only.\n- Some connection and shell workflows depend on local `mysql` or `psql` clients, and `pscale shell` is interactive unless you explicitly allow non-interactive use.", "category": "databases", "install": "brew install planetscale\/tap\/pscale", "github": "https:\/\/github.com\/planetscale\/cli", "website": "https:\/\/planetscale.com\/docs\/cli", "source_url": null, "stars": 647, "language": "Go", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "PlanetScale" }, { "slug": "wireguard", "name": "WireGuard", "description": "WireGuard CLI for generating keys, inspecting tunnel status, and configuring encrypted VPN interfaces and peers.", "long_description": "WireGuard tools are the userspace commands for configuring WireGuard tunnel interfaces across platforms. The core `wg` utility manages keys, peers, and runtime state, while `wg-quick` handles simple bring-up and teardown from config files.\n\n## What It Enables\n- Generate private, public, and preshared keys and inspect interfaces, peers, endpoints, handshakes, and transfer counters on a host.\n- Apply, append, sync, or export interface and peer configuration with `set`, `setconf`, `addconf`, `syncconf`, and `showconf`.\n- Bring tunnels up or down from config files, derive routes from allowed IPs, and attach DNS or firewall hooks for simple VPN client or server setups.\n\n## Agent Fit\n- Core commands are non-interactive and `wg show` supports field-specific reads plus `dump` output, so shell scripts can inspect live tunnel state without parsing the pretty terminal view.\n- Useful for local inspect-change-verify loops around peer rollout, key rotation, endpoint checks, and tunnel reloads; `syncconf` is designed to change config without disrupting current sessions.\n- Automation limits are operational rather than conceptual: mutating flows usually need root, direct host access, and careful handling of private keys plus OS networking side effects.\n\n## Caveats\n- There is no native JSON output in the main CLI; machine-readable reads use tab and newline-oriented text, and the JSON helper lives only in `contrib\/`.\n- `wg-quick` is intentionally a simple wrapper around `wg` and system networking tools, so advanced environments may be better served by a dedicated network manager or direct `wg` plus OS commands.", "category": "networking", "install": "brew install wireguard-tools", "github": "https:\/\/github.com\/WireGuard\/wireguard-tools", "website": "https:\/\/www.wireguard.com\/", "source_url": null, "stars": 638, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "WireGuard" }, { "slug": "wacli", "name": "wacli", "description": "WhatsApp CLI for syncing chats locally, searching message history, sending messages, and managing contacts or groups.", "long_description": "wacli is a third-party WhatsApp CLI built on the WhatsApp Web protocol via `whatsmeow`. It links a personal WhatsApp account, stores synced state locally, and exposes message, contact, media, and group operations from the shell.\n\n## What It Enables\n- Authenticate once, keep a local SQLite copy of chats and messages, and search or inspect message history offline from the terminal.\n- Send text or files, download message media, and request older history for a specific chat from your primary device when WhatsApp supports it.\n- List chats, contacts, and groups, refresh synced metadata, and manage group names, participants, invite links, joins, or leaves without leaving the shell.\n\n## Agent Fit\n- Global `--json` output and mostly flag-driven subcommands make it workable in inspect-change-verify loops after the initial account link is in place.\n- It is useful for agents that need direct access to a linked personal WhatsApp account, especially when local sync plus offline search is more reliable than scraping a web UI.\n- Unattended use is constrained by QR-based auth, single-store locking, and WhatsApp-side limits such as best-effort history sync and some flows depending on the primary device being online.\n\n## Caveats\n- This is an unofficial third-party client using the WhatsApp Web protocol and is explicitly not affiliated with WhatsApp.\n- History coverage is not a guaranteed export; the local database only contains what sync and backfill can obtain from WhatsApp Web and your phone.", "category": "utilities", "install": "brew install steipete\/tap\/wacli", "github": "https:\/\/github.com\/steipete\/wacli", "website": null, "source_url": null, "stars": 607, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "whatsapp", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "b2", "name": "Backblaze B2 CLI", "description": "Official Backblaze B2 CLI for bucket, file, sync, replication, and application-key operations.", "long_description": "Backblaze B2 CLI is the official command line client for Backblaze B2 Cloud Storage. It covers account authorization, bucket and file operations, bulk sync, application keys, replication, and notification rules for object storage workflows.\n\n## What It Enables\n- Authorize against a B2 account, inspect buckets or files, and create, update, or delete buckets, keys, and object metadata from the shell.\n- Sync local folders to B2, download or copy objects between local paths and buckets, and automate recurring backup or transfer jobs.\n- Manage replication and notification rules, generate download authorization tokens or URLs, and script follow-up storage operations around those results.\n\n## Agent Fit\n- List and info commands expose real `--json` output, and the code explicitly recommends JSON for scripts because human-readable output can change across minor releases.\n- The CLI is usable in unattended flows with env-based credentials, non-interactive subcommands, and dry-run support on `sync` and `rm`.\n- For long-lived automation, Backblaze recommends the version-pinned `b2v4` interface instead of floating `b2`, which fits durable agent workflows better.\n\n## Caveats\n- Useful operation starts with B2 credentials; `account authorize` prompts by default unless keys are supplied through environment variables or arguments.\n- Some high-impact commands are intentionally sharp, especially `sync --delete`, so agents should stage changes with `--dry-run` and explicit scopes.", "category": "cloud", "install": "brew install b2-tools", "github": "https:\/\/github.com\/Backblaze\/B2_Command_Line_Tool", "website": "https:\/\/b2-command-line-tool.readthedocs.io\/", "source_url": "https:\/\/www.backblaze.com\/docs\/cloud-storage-command-line-tools", "stars": 600, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Backblaze" }, { "slug": "vultr", "name": "Vultr CLI", "description": "Official Vultr CLI for managing instances, networking, Kubernetes, DNS, storage, and databases on Vultr.", "long_description": "Vultr CLI is the official command line wrapper for the Vultr API. It covers compute, networking, storage, Kubernetes, DNS, and account-level operations from one shell surface.\n\n## What It Enables\n- Provision, inspect, reboot, tag, and delete instances, bare metal servers, snapshots, ISOs, and startup scripts.\n- Manage platform services such as DNS records, firewalls, load balancers, VPCs, reserved IPs, object storage, container registries, and managed databases.\n- Discover regions, plans, operating systems, marketplace apps, and Kubernetes versions before creating or updating clusters and node pools.\n\n## Agent Fit\n- Global `--output` support for JSON and YAML makes the same commands usable for human inspection and machine parsing.\n- Most operations are exposed as explicit subcommands and flags rather than interactive flows, so they fit scripts, CI jobs, and inspect\/change\/verify loops well.\n- Automation works best in a pre-authenticated Vultr environment and should opt into `-o json` instead of parsing the default text tables.\n\n## Caveats\n- Most write operations require `VULTR_API_KEY` or config-based auth, so the unauthenticated surface is limited.\n- The CLI only manages Vultr resources; work inside deployed servers or clusters still needs other tools.", "category": "cloud", "install": "brew install vultr\/vultr-cli\/vultr-cli", "github": "https:\/\/github.com\/vultr\/vultr-cli", "website": "https:\/\/docs.vultr.com\/reference\/vultr-cli", "source_url": "https:\/\/github.com\/vultr\/vultr-cli", "stars": 533, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Vultr" }, { "slug": "ghost-cli", "name": "Ghost CLI", "description": "Ghost CLI for installing, configuring, updating, backing up, and operating self-hosted Ghost sites.", "long_description": "Ghost CLI is Ghost's server-side operations tool for setting up and maintaining self-hosted Ghost installs. It covers install and update workflows, process control, configuration, diagnostics, logs, and content backup or migration tasks for a site on disk.\n\n## What It Enables\n- Install Ghost on the recommended stack, run staged setup for nginx, SSL, MySQL, and systemd, and create local installs for theme development or testing.\n- Start, stop, restart, update, roll back, and list Ghost instances from the shell, with `doctor` checks before common operations.\n- Export or import site content, generate backups with content, members, themes, and media, inspect logs, and edit site configuration without using the admin UI.\n\n## Agent Fit\n- Useful for agents operating a known Ghost host because commands are direct, non-TUI, and expose global controls like `--dir`, `--no-prompt`, and `--auto`.\n- Automation is limited by human-oriented output: there is no general JSON mode, and inspection commands mainly return tables, formatted logs, and status text.\n- Best fit for server maintenance workflows around an existing Ghost install, where the agent also has filesystem access, any needed privileges, and Ghost admin credentials or staff tokens.\n\n## Caveats\n- Production setup is intentionally opinionated around Ghost's recommended stack, so support outside that path is limited.\n- Backup and export or import flows may prompt for admin credentials or rely on `GHOST_CLI_STAFF_AUTH_TOKEN`, and some setup or file operations need elevated privileges.", "category": "http-apis", "install": "npm install -g ghost-cli@latest", "github": "https:\/\/github.com\/TryGhost\/Ghost-CLI", "website": "https:\/\/docs.ghost.org\/ghost-cli", "source_url": "https:\/\/ghost.org\/docs\/ghost-cli\/", "stars": 489, "language": "JavaScript", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Ghost" }, { "slug": "deck", "name": "decK", "description": "Kong declarative configuration CLI for diffing, syncing, validating, exporting, and transforming Gateway or Konnect state.", "long_description": "decK is Kong's declarative configuration CLI for comparing, exporting, validating, and applying gateway state. It works against Kong Gateway and Konnect control planes while also providing local file transforms for common API ops workflows.\n\n## What It Enables\n- Export live gateway or Konnect configuration, diff it against versioned state files, and sync or partially apply changes back through the Admin API.\n- Validate, render, merge, patch, tag, and lint decK files locally before rollout, including dry-run style drift checks and sanitized dumps.\n- Convert OpenAPI specs into decK state, or transform decK files into Kong Ingress Controller manifests and Terraform resources for downstream delivery workflows.\n\n## Agent Fit\n- JSON output is real on drift-oriented commands like `gateway diff`, `gateway sync`, and `gateway reset`, and multiple file subcommands can emit JSON for follow-up parsing.\n- Commands are mostly scriptable once credentials are in place, with stdin or stdout defaults plus `--yes` or `--force` flags that fit inspect-change-verify loops and CI.\n- Best fit is teams already managing Kong declaratively; it is less useful as a generic API client, and live operations depend on reachable Kong or Konnect endpoints.\n\n## Caveats\n- `deck gateway apply` advertises `--json-output`, but `cmd\/gateway_apply.go` binds that flag to the wrong variable, so structured apply output appears broken.\n- Several top-level commands and the `konnect` group remain for backward compatibility but are marked deprecated in favor of `deck gateway` and `deck file`.", "category": "networking", "install": "brew install kong\/deck\/deck", "github": "https:\/\/github.com\/Kong\/deck", "website": "https:\/\/docs.konghq.com\/deck\/overview", "source_url": "https:\/\/docs.konghq.com\/deck\/overview", "stars": 487, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Kong" }, { "slug": "railway", "name": "Railway CLI", "description": "Official Railway CLI for deploying projects and managing Railway services, environments, logs, domains, and storage.", "long_description": "Railway CLI is Railway's official command surface for deploying and operating hosted projects from the shell. It covers project setup, service management, environment configuration, logs, storage, network endpoints, and local development helpers tied to Railway projects.\n\n## What It Enables\n- Create or link projects and services, deploy the current directory or a template, and redeploy, restart, or scale services without leaving the terminal.\n- Inspect project, service, and deployment state; stream build or deploy logs; manage environment variables; and open SSH, database, or local shell sessions with Railway context.\n- Manage Railway-specific resources such as environments, domains, buckets, volumes, and project functions, and generate local Docker Compose setups with `railway dev`.\n\n## Agent Fit\n- High-value inspect and mutate commands expose real `--json` output, which makes follow-up parsing practical for status checks, deploy flows, logs, variables, and resource management.\n- Once credentials and project context are in place, the noun-verb command structure works well for inspect\/change\/verify loops in CI or local automation.\n- Login, project or service selection, confirmation prompts, SSH or shell sessions, and the default `dev` TUI still introduce interactive edges that agents need to bypass with explicit flags or preset context.\n\n## Caveats\n- Many commands assume a linked project, environment, or service; in non-interactive mode you often need to pass explicit names or IDs.\n- JSON output is broad but not universal, and some workflows hand off to other tools such as Docker, `psql`, `mongosh`, `mysql`, `redis-cli`, or an interactive shell.", "category": "cloud", "install": "brew install railway", "github": "https:\/\/github.com\/railwayapp\/cli", "website": "https:\/\/docs.railway.com\/cli", "source_url": "https:\/\/docs.railway.com\/cli", "stars": 483, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Railway" }, { "slug": "circleci", "name": "CircleCI CLI", "description": "Official CircleCI CLI for validating configs, managing pipelines and project settings, and administering CircleCI runners.", "long_description": "CircleCI CLI is the official command surface for working with CircleCI config, projects, pipelines, contexts, orbs, and self-hosted runners. It spans both local config workflows and authenticated account or organization operations against CircleCI APIs.\n\n## What It Enables\n- Validate, pack, process, and generate CircleCI config files, then run a named job locally in Docker with `local execute`.\n- List or manage contexts, project secrets, projects, pipeline definitions, and pipeline runs from the terminal instead of the web UI.\n- Administer self-hosted runner resource classes, tokens, and instances, and inspect organization metadata for follow-up automation.\n\n## Agent Fit\n- Good shell fit for config validation, local CI debugging, and scripted admin tasks because most commands are flag-driven and return clear success or failure states.\n- Structured output is real but uneven: JSON is available for contexts, org info, project secrets, runners, and orb listings, while pipeline and local-execute flows mostly print human text.\n- Best used by agents that can hold CircleCI credentials and prefill required flags; setup, pipeline create, and pipeline run fall back to interactive prompts when inputs are missing.\n\n## Caveats\n- Authenticated commands need a CircleCI API token, and setup defaults interactive unless you use the hidden `setup --no-prompt` path.\n- `local execute` depends on Docker and CircleCI's config processing, and some legacy commands still proxy to `circleci-agent` only inside CircleCI jobs.", "category": "testing", "install": "brew install circleci", "github": "https:\/\/github.com\/CircleCI-Public\/circleci-cli", "website": "https:\/\/circleci-public.github.io\/circleci-cli\/", "source_url": "https:\/\/circleci-public.github.io\/circleci-cli\/", "stars": 432, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "CircleCI" }, { "slug": "linode-cli", "name": "Linode CLI", "description": "Official Linode CLI for managing compute, networking, domains, storage, Kubernetes, databases, and account resources from the shell.", "long_description": "linode-cli is Linode's official command line wrapper around the Linode API for managing Akamai Cloud resources and account settings. It exposes most day-to-day infrastructure actions through generated subcommands plus a few bundled plugins for workflows the raw API surface does not cover cleanly.\n\n## What It Enables\n- Create, inspect, update, reboot, resize, rebuild, and delete Linodes, disks, volumes, firewalls, NodeBalancers, VPCs, VLANs, domains, and IP or DNS settings from the shell.\n- Manage broader account surfaces such as users, profile data, events, tickets, maintenance, managed databases, Kubernetes clusters, and beta or monitoring resources.\n- Use bundled helpers for object storage buckets and objects, kubeconfig retrieval, image upload, metadata queries, and SSH handoff without dropping to raw API calls.\n\n## Agent Fit\n- Real `--json`, `--pretty`, `--text`, `--delimiter`, and `--format` output controls make it practical to parse results instead of scraping tables.\n- Because the CLI is generated from the OpenAPI spec and covers many service areas, it works well as a direct inspect\/change layer for automation once credentials are in place.\n- First-run configuration is browser-first by default, and some helpers like `ssh` intentionally hand off to interactive programs, so unattended flows work best with `LINODE_CLI_TOKEN` or `configure --token`.\n\n## Caveats\n- Default output is a human-readable table and warnings can be emitted on stderr; automation should usually opt into `--json` and often `--suppress-warnings`.\n- The `obj` plugin needs extra object-storage credentials and the optional `boto3` dependency for bucket and object operations.", "category": "cloud", "install": "pip3 install linode-cli --upgrade", "github": "https:\/\/github.com\/linode\/linode-cli", "website": "https:\/\/techdocs.akamai.com\/cloud-computing\/docs\/getting-started-with-the-linode-cli", "source_url": "https:\/\/www.linode.com\/docs\/products\/tools\/cli\/", "stars": 420, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Linode" }, { "slug": "sonar-scanner", "name": "SonarScanner CLI", "description": "Code analysis scanner CLI for SonarQube Server and SonarQube Cloud projects.", "long_description": "SonarScanner CLI is SonarSource's generic scanner for running source-code analysis against SonarQube Server or SonarQube Cloud when there is no build-system-specific scanner to use. It reads analysis parameters from project config, environment variables, and `-D` flags, then sends the scan to the Sonar service.\n\n## What It Enables\n- Analyze a checked-out project from a local shell, CI job, or container runner and upload the resulting scan to SonarQube for quality and security evaluation.\n- Drive scans from `sonar-project.properties`, alternate project settings files, environment variables, or inline `-D` properties, including scanning a different project base directory from the current working directory.\n- Use a generic scanner path for repos that are not covered by a more specialized Sonar scanner, then fold that step into CI gates or other automated quality checks.\n\n## Agent Fit\n- Commands are non-interactive, configuration is entirely file\/env\/flag driven, and exit codes cleanly signal success versus scanner or user errors.\n- Automation is weaker on the read side because local output is log-oriented rather than structured JSON, so agents usually rely on exit status here and query SonarQube separately for findings or quality-gate details.\n- Best fit is as one step in a broader workflow that prepares the checkout, injects `SONAR_TOKEN` and server settings, runs the scan, and verifies results through Sonar-side APIs or dashboards.\n\n## Caveats\n- Useful operation requires a reachable SonarQube Server or SonarQube Cloud instance plus auth and project configuration; the CLI does not provide standalone local issue triage.\n- It is not the right scanner for every stack: the docs explicitly call out .NET projects as needing the dedicated SonarScanner for .NET, and build-specific scanners can be a better fit when available.", "category": "security", "install": "brew install sonar-scanner", "github": "https:\/\/github.com\/SonarSource\/sonar-scanner-cli", "website": "https:\/\/docs.sonarsource.com\/sonarqube-server\/analyzing-source-code\/scanners\/sonarscanner", "source_url": "https:\/\/docs.sonarsource.com\/sonarqube-server\/analyzing-source-code\/scanners\/sonarscanner", "stars": 413, "language": "Java", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "SonarSource" }, { "slug": "mongosh", "name": "MongoDB Shell", "description": "Official MongoDB shell for querying, scripting, and administering MongoDB deployments from the terminal.", "long_description": "Mongosh is MongoDB's official shell for connecting to databases, running JavaScript against the MongoDB Shell API, and working interactively or from scripts. It covers both everyday data inspection and server-side admin tasks from one terminal entry point.\n\n## What It Enables\n- Connect to local or remote MongoDB deployments and run collection queries, CRUD operations, and aggregation pipelines through `db` and collection APIs.\n- Execute repeatable `.js` files or one-off `--eval` snippets for data checks, maintenance tasks, migrations, or smoke tests with connection, auth, TLS, and API-version flags on the same command.\n- Inspect or administer replica set and sharding state through built-in helpers such as `rs` and `sh`, including status, balancing, and topology-related operations.\n\n## Agent Fit\n- `--eval` plus `--json[=canonical|relaxed]` gives machine-readable Extended JSON results and serialized errors, which is useful for inspect and verify steps.\n- Automation is less uniform than in subcommand-driven CLIs: structured output is limited to `--eval`, while file execution and REPL output stay human-oriented unless your script prints its own machine-readable data.\n- Best fit when an agent can generate or reuse Mongo shell JavaScript for database workflows; less ideal when you want narrow verbs and consistent JSON on every path.\n\n## Caveats\n- Useful work requires a reachable MongoDB deployment plus the right credentials, and some auth flows can still prompt interactively.\n- This is a programmable shell rather than a small set of fixed commands, so safety and repeatability depend heavily on the script you run.", "category": "databases", "install": "npx mongosh", "github": "https:\/\/github.com\/mongodb-js\/mongosh", "website": "https:\/\/www.mongodb.com\/docs\/mongodb-shell\/", "source_url": "https:\/\/www.mongodb.com\/docs\/mongodb-shell\/", "stars": 383, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "MongoDB" }, { "slug": "contentful-cli", "name": "Contentful CLI", "description": "Official Contentful CLI for spaces, environments, migrations, content imports and exports, and organization checks.", "long_description": "Contentful CLI is Contentful's command line client for administering spaces and environments and for moving structured content between them. It also covers schema and migration work, organization-level exports and security checks, and a few onboarding or merge workflows.\n\n## What It Enables\n- Create, list, delete, and select spaces or environments, manage environment aliases and access tokens, and inspect content types from the shell.\n- Export space data to JSON, import exported content into another space, run migration scripts, seed templates, and generate migration files from existing spaces.\n- Export organization taxonomy data, run organization security checks, and compare two environments or export their diff as a migration.\n\n## Agent Fit\n- Useful as a direct CMS control surface for backup, migration, environment-management, and governance workflows because commands are explicit and scriptable once auth and context are set.\n- Machine-readable output exists for some high-value paths, but it is not consistent across the CLI: several inspect commands still render tables instead of offering a uniform `--json` mode.\n- Best in agent loops after bootstrap, since default login, `init`, and some space or environment selection flows open a browser or prompt interactively.\n\n## Caveats\n- Requires a Contentful Management API token, and the default login flow stores context in `~\/.contentfulrc.json` after browser-based authorization or token entry.\n- Coverage is not complete for every CMS admin task: export and import docs call out limits around memberships, roles, credentials, and some extension handling, and merge features depend on Contentful app actions.", "category": "http-apis", "install": "npm install -g contentful-cli", "github": "https:\/\/github.com\/contentful\/contentful-cli", "website": "https:\/\/www.contentful.com\/developers\/docs\/tutorials\/cli\/", "source_url": "https:\/\/www.contentful.com\/developers\/docs\/tutorials\/cli\/", "stars": 352, "language": "JavaScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Contentful" }, { "slug": "doppler", "name": "Doppler CLI", "description": "Secrets management CLI for Doppler projects, configs, service tokens, and secret-injected command runs.", "long_description": "Doppler CLI manages secrets and environment configuration stored in Doppler workspaces, projects, and configs from the shell. It covers both secret consumption in apps and administrative tasks like project setup, service token management, and activity log inspection.\n\n## What It Enables\n- Read, set, delete, upload, download, and template-substitute secrets for a selected project\/config, or run commands with those secrets injected into the environment.\n- Create and manage projects, environments, configs, and config service tokens without switching to the web dashboard.\n- Inspect workplace activity logs and import project templates so secret changes and environment structure can be audited and reproduced.\n\n## Agent Fit\n- A global `--json` flag and broad CRUD-style subcommands make inspect, change, and verify loops straightforward.\n- Works well in scripts once a token and target config are already set, and commands like `run`, `secrets download`, and token creation map cleanly to automation.\n- Login and some setup or destructive flows still lean interactive, with browser auth, confirmations, and repo-scoped config prompts to account for.\n\n## Caveats\n- You need a Doppler account plus auth tokens or browser login before most commands do anything useful.\n- Unattended use works best when project\/config scope is already configured or always passed explicitly, otherwise setup and confirmation prompts get in the way.", "category": "security", "install": "brew install dopplerhq\/cli\/doppler", "github": "https:\/\/github.com\/DopplerHQ\/cli", "website": "https:\/\/docs.doppler.com\/docs\/start", "source_url": null, "stars": 349, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Doppler" }, { "slug": "socat", "name": "socat", "description": "Byte-stream relay CLI for sockets, files, devices, tunnels, proxies, and port forwarding.", "long_description": "socat is a low-level relay CLI that opens two addresses and copies bytes between them. It covers socket bridging, protocol adaptation, and network plumbing across sockets, files, devices, and spawned programs.\n\n## What It Enables\n- Bridge TCP, UDP, UNIX sockets, serial devices, files, pipes, PTYs, or spawned commands without writing custom glue code.\n- Build ad hoc listeners, port forwards, proxy hops, TLS-wrapped relays, or shell-accessible endpoints for debugging, migration, and incident work.\n- Create niche transports such as multicast or broadcast flows and TUN-backed links when you need to move traffic between mismatched interfaces.\n\n## Agent Fit\n- Non-interactive commands, shell pipes, exit codes, and `-h` or `-V` introspection make it workable in inspect, change, and verify loops.\n- There is no JSON or other structured output; diagnostics and transfer traces are text-oriented, so reliable automation usually needs custom parsing or a skill.\n- Best when an agent already knows the addresses and options it needs, because `socat` is a transport primitive rather than a service-aware CLI.\n\n## Caveats\n- Address strings are dense and quoting-sensitive, especially with `EXEC`, `SYSTEM`, dual addresses, and shell metacharacters.\n- Upstream security guidance warns that broad feature builds can expose file and exec surfaces; listening relays and `exec` or `system` usage need tight scoping.", "category": "networking", "install": "brew install socat", "github": "https:\/\/github.com\/3ndG4me\/socat", "website": "http:\/\/www.dest-unreach.org\/socat\/", "source_url": "http:\/\/www.dest-unreach.org\/socat\/", "stars": 310, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "auth0", "name": "Auth0 CLI", "description": "Official Auth0 CLI for managing tenant resources, actions, logs, and login or token test flows from the terminal.", "long_description": "Auth0 CLI is the official command line client for configuring and testing Auth0 tenants. It covers core identity admin work such as applications, APIs, users, organizations, actions, branding, logs, and direct Management API calls.\n\n## What It Enables\n- Create, update, list, and delete tenant resources such as applications, APIs, users, organizations, roles, custom domains, attack-protection settings, log streams, and event streams.\n- Test Universal Login and token issuance, inspect branding or prompt settings, tail tenant logs, and troubleshoot identity flows without living in the dashboard.\n- Script deeper admin work with `auth0 api` requests and export existing tenant resources into Terraform configuration with `auth0 terraform generate`.\n\n## Agent Fit\n- Many list, show, create, update, and test commands expose `--json` or `--json-compact`, and `auth0 api` always returns JSON, so follow-up parsing is straightforward.\n- Automation fit is good once auth is configured: the CLI has `--no-input`, supports machine login with client credentials or private-key JWT, and covers inspect-change-verify loops across tenant resources.\n- The surface is mixed rather than fully headless because some commands intentionally open a browser, dashboard page, or local editor for login, testing, or customization work.\n\n## Caveats\n- Useful operation requires an Auth0 tenant plus valid credentials; user login uses device and browser flow, while unattended use depends on machine credentials and requested scopes.\n- `auth0 universal-login customize` mixes browser and editor workflows, and its advanced mode is marked deprecated in favor of `auth0 acul config`.", "category": "security", "install": "brew tap auth0\/auth0-cli && brew install auth0", "github": "https:\/\/github.com\/auth0\/auth0-cli", "website": "https:\/\/auth0.github.io\/auth0-cli\/", "source_url": "https:\/\/auth0.github.io\/auth0-cli\/", "stars": 308, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Auth0" }, { "slug": "drizzle-kit", "name": "drizzle-kit", "description": "Drizzle ORM CLI for generating SQL migrations, introspecting databases, applying migrations, and pushing schema changes.", "long_description": "drizzle-kit is the schema and migration CLI for Drizzle ORM. It compares code-defined schemas with prior snapshots or live databases to generate SQL, apply migrations, introspect existing databases, and push schema changes.\n\n## What It Enables\n- Generate SQL migration files from Drizzle schema changes, including empty custom migrations when a change cannot be expressed from the schema diff alone.\n- Apply migrations, validate or upgrade local migration snapshot metadata, and remove the latest recorded migration from a local migrations folder.\n- Introspect existing Postgres, MySQL, SQLite, Turso, SingleStore, or Gel databases into Drizzle files, or push schema diffs directly to a target database.\n\n## Agent Fit\n- Core commands are plain subcommands with explicit flags, config-file support, and exit-on-error behavior, so they fit repo-local inspect and change loops well.\n- Several high-impact paths still require human decisions: rename conflict resolution prompts during generation, approval prompts for destructive `push` statements, and an interactive selector for `drop`.\n- Automation has to work with generated files and human-oriented stdout because the CLI does not expose native JSON output; `studio` also shifts the workflow into a local web UI rather than a pure shell loop.\n\n## Caveats\n- The listed GitHub repo is an archived mirror; the maintained source now lives inside the `drizzle-orm` monorepo.\n- Most useful commands depend on a project-specific Drizzle config and working database credentials, so the CLI is strongest when an agent already has repo context and environment setup.", "category": "databases", "install": "npm install -D drizzle-kit", "github": "https:\/\/github.com\/drizzle-team\/drizzle-kit-mirror", "website": "https:\/\/orm.drizzle.team\/kit-docs\/overview", "source_url": "https:\/\/orm.drizzle.team\/docs\/drizzle-kit-overview", "stars": 288, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Drizzle" }, { "slug": "turso", "name": "Turso CLI", "description": "Turso CLI for creating, replicating, querying, importing, and operating Turso databases, groups, and orgs.", "long_description": "Turso CLI is Turso's official command-line client for provisioning and operating Turso\/libSQL databases, groups, and organization settings. It also includes direct SQL access through `turso db shell` and a `dev` command that starts a local `sqld` server for local development.\n\n## What It Enables\n- Create, import, export, destroy, and replicate Turso databases, then inspect usage, instances, URLs, and config without opening the dashboard.\n- Generate database or API tokens, manage groups, org members, invites, audit logs, and transfer databases or groups between organizations.\n- Run one-off SQL queries or an interactive SQL shell against a Turso database or replica URL, and start a local `sqld` server against an ephemeral or file-backed SQLite database.\n\n## Agent Fit\n- The CLI exposes real inspect and mutation coverage with ordinary subcommands and flags, so it fits shell-driven inspect\/change\/verify loops.\n- Headless login guidance plus token-based auth and one-shot `turso db shell ` usage make unattended workflows possible when credentials are already in place.\n- Automation is weaker than the current row suggests: repo docs and command definitions show text and table output but no documented `--json` or `--output` mode, so parsing often means scraping human-oriented stdout.\n\n## Caveats\n- Default login opens a browser, so CI and remote agents need headless auth flow or preprovisioned tokens.\n- Some commands still prompt in TTY contexts or require confirmations unless you pass the relevant flags.", "category": "databases", "install": "brew install tursodatabase\/tap\/turso", "github": "https:\/\/github.com\/tursodatabase\/turso-cli", "website": "https:\/\/docs.turso.tech\/reference\/turso-cli", "source_url": null, "stars": 287, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Turso" }, { "slug": "sshpass", "name": "sshpass", "description": "Non-interactive SSH password helper for scripting legacy systems that cannot use key-based authentication.", "long_description": "sshpass is a small wrapper that feeds a password to ssh and other SSH-based commands when a remote system still requires keyboard-interactive authentication. It is mainly a compatibility tool for legacy hosts where key-based auth is unavailable or cannot be enabled.\n\n## What It Enables\n- Run ssh, scp, rsync, or other SSH-based commands non-interactively against password-only systems.\n- Pass credentials from stdin, a file, an inherited file descriptor, or the `SSHPASS` environment variable instead of typing at a prompt.\n- Handle common failure cases such as wrong passwords or unknown host keys through exit codes inside scripts.\n\n## Agent Fit\n- It fits shell automation cleanly because it wraps existing SSH commands and exits non-interactively once arguments are set.\n- Machine-readable output is minimal: there is no JSON mode, so most follow-up logic has to use exit codes plus stderr from ssh or the wrapped command.\n- Best used as a narrow legacy-access helper inside a larger workflow, not as a general remote-management CLI.\n\n## Caveats\n- Password automation is weaker than SSH key-based auth; the man page explicitly recommends public key authentication when possible.\n- The `-p` flag is the least secure option because other users can inspect process arguments, so stdin, file descriptor, file, or environment-based handoff is safer.", "category": "security", "install": "brew install sshpass", "github": "https:\/\/github.com\/kevinburke\/sshpass", "website": "https:\/\/sourceforge.net\/projects\/sshpass\/", "source_url": "https:\/\/sourceforge.net\/projects\/sshpass\/", "stars": 250, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "docs", "vendor_name": null }, { "slug": "akamai", "name": "Akamai CLI", "description": "Official Akamai CLI launcher for discovering, installing, and running Akamai product command packages.", "long_description": "Official Akamai umbrella CLI that installs and dispatches Akamai product command packages from one entry point. The base binary handles shared auth, config, package discovery, and upgrades rather than exposing most Akamai service actions itself.\n\n## What It Enables\n- Discover, install, update, and remove Akamai product packages such as Property Manager, Purge, Edge DNS, EdgeWorkers, and Sandbox.\n- Run installed Akamai product commands behind a common `akamai ` interface with shared `.edgerc`, section, and account switch flags.\n- Manage local CLI configuration and package versions for Akamai API workflows without wiring each package manually.\n\n## Agent Fit\n- Shared flags, explicit exit codes, and non-interactive package commands make the launcher usable in setup scripts and agent-run shell flows.\n- The base CLI's own output is human-oriented text for help, search, list, and config commands, so structured parsing is limited.\n- Best fit as a bootstrap and control layer for Akamai automation; the actual inspect and change operations usually live in separately installed packages.\n\n## Caveats\n- Most useful Akamai operations require installing a product-specific package first.\n- Installed commands still depend on valid `.edgerc` credentials and product entitlements.", "category": "networking", "install": "brew install akamai", "github": "https:\/\/github.com\/akamai\/cli", "website": "https:\/\/techdocs.akamai.com\/developer\/docs\/cli", "source_url": "https:\/\/techdocs.akamai.com\/developer\/docs\/about-clis", "stars": 229, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Akamai" }, { "slug": "sag", "name": "sag", "description": "ElevenLabs text-to-speech CLI for speaking text, browsing voices, and saving audio from the terminal.", "long_description": "Unofficial ElevenLabs text-to-speech CLI that mimics macOS `say`, with voice lookup, optional speaker playback, and audio file output from the terminal.\n\n## What It Enables\n- Generate spoken audio from text arguments, stdin, or input files and either play it immediately or save MP3 or WAV output.\n- Browse available ElevenLabs voices, filter them by name, labels, or semantic query text, and preview samples before choosing one.\n- Tune model, rate, speed, latency, and voice settings so scripted voiceovers, alerts, or narration steps can be repeated from the shell.\n\n## Agent Fit\n- Commands are flag-driven and non-interactive once credentials and a voice are set, so agents can call it directly in media-generation workflows.\n- Machine readability is weak: voice listings are tabular, synthesis returns audio streams or files, and the only structured data is internal API traffic rather than CLI output.\n- Best fit for a narrow step inside a larger automation, such as rendering narration or audible alerts, rather than inspecting or mutating complex service state.\n\n## Caveats\n- Requires an ElevenLabs account and API key before most commands work.\n- A lot of the product value is human-facing playback and voice choice, so unattended automation is narrower than the README feature list suggests.", "category": "utilities", "install": "brew install steipete\/tap\/sag # auto-taps steipete\/tap", "github": "https:\/\/github.com\/steipete\/sag", "website": null, "source_url": null, "stars": 217, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "civo", "name": "Civo CLI", "description": "Official Civo CLI for managing Civo instances, Kubernetes clusters, networking, databases, object storage, and account settings.", "long_description": "Civo CLI is Civo's official command line for provisioning and inspecting cloud resources across compute, Kubernetes, networking, storage, databases, DNS, and account-level settings. It acts as the main shell control surface for a Civo account rather than a narrow single-service wrapper.\n\n## What It Enables\n- Create, inspect, update, and delete instances, Kubernetes clusters and node pools, networks, firewalls, IPs, volumes, and VPC resources from one CLI.\n- Manage databases, backups, restores, resource snapshots, object stores, object store credentials, SSH keys, teams, permissions, quotas, and regions without leaving the terminal.\n- Fetch kubeconfig for clusters and export object store credentials for follow-on tooling when you need to bridge from Civo account operations into Kubernetes or S3-compatible workflows.\n\n## Agent Fit\n- Global `-o json`, `-f\/--fields`, `--pretty`, `--region`, and `-y\/--yes` flags make many inspect, create, and delete flows usable in scripts and inspect\/change\/verify loops.\n- Auth can be driven from saved config or `CIVO_TOKEN`, which is useful for CI and unattended runs, and the command surface is broad enough to cover most routine Civo account operations directly.\n- The fit is not perfectly uniform: some commands are human-oriented or side-effect focused, such as kubeconfig updates and credential export flows that do not behave like clean JSON-first resource commands.\n\n## Caveats\n- You need Civo API credentials and region context in `.civo.json` or environment variables before most commands do useful work.\n- Load balancer support is incomplete in this repo, with only list and show wired while create, update, and remove remain commented out.", "category": "cloud", "install": "brew tap civo\/tools && brew install civo", "github": "https:\/\/github.com\/civo\/cli", "website": "https:\/\/www.civo.com\/docs", "source_url": "https:\/\/github.com\/civo\/cli", "stars": 203, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Civo" }, { "slug": "twilio", "name": "Twilio CLI", "description": "Official Twilio CLI for Twilio API operations, account profiles, phone numbers, and plugins.", "long_description": "Twilio CLI is Twilio's official command-line client for working with Twilio accounts and APIs from the shell. It combines generated API commands with a few higher-level commands for profiles, phone numbers, debugger logs, email sending, and plugins.\n\n## What It Enables\n- Create, list, fetch, update, and delete Twilio resources through generated `twilio api:*` commands that mirror much of the Twilio API surface.\n- Manage multiple accounts or regions with stored profiles or environment variables, then inspect or update resources like phone numbers and webhooks from the terminal.\n- Inspect debugger log events, send email through Twilio SendGrid, and extend the CLI with Twilio or custom plugins for product-specific workflows.\n\n## Agent Fit\n- `-o json`, TSV output, `--properties`, and stdout\/stderr separation make API responses easy to parse and chain with tools like `jq`.\n- Help text and command discovery are strong because the CLI generates topics and flags from Twilio's API definitions, which works well in try, inspect, and retry loops.\n- Unattended use is best after credentials are preconfigured; `twilio login` is interactive, some commands default to human tables, and plugins add another trust surface.\n\n## Caveats\n- First-time setup usually prompts for Account SID and Auth Token, unless you provide environment variables or flags up front.\n- List commands default to 50 records and the default displayed columns can change, so automation should set `--limit`, `--properties`, and JSON output explicitly.", "category": "utilities", "install": "brew tap twilio\/brew && brew install twilio", "github": "https:\/\/github.com\/twilio\/twilio-cli", "website": "https:\/\/www.twilio.com\/docs\/twilio-cli\/quickstart", "source_url": null, "stars": 187, "language": "JavaScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Twilio" }, { "slug": "hubspot-cli", "name": "HubSpot CLI", "description": "Official HubSpot CLI for HubSpot projects, CMS assets, HubDB tables, test accounts, and developer account workflows.", "long_description": "HubSpot CLI is HubSpot's official command surface for building and operating HubSpot projects from the shell. It also covers CMS asset sync, HubDB and custom object work, and developer account utilities such as sandboxes, secrets, and test accounts.\n\n## What It Enables\n- Create, upload, deploy, validate, download, and run local dev flows for HubSpot projects, including build status, logs, and profile-targeted deployments.\n- Sync CMS assets, themes, templates, modules, serverless functions, and File Manager content between local directories and HubSpot accounts.\n- Create or inspect HubDB tables and custom object schemas, manage app or account secrets, and provision sandboxes or test accounts for development work.\n\n## Agent Fit\n- Explicit subcommands and flags make it usable in shell workflows, and the CLI has real JSON output for a subset of high-value commands such as project upload or deploy, test-account creation, and CMS function listing.\n- Automation fit is uneven because many other commands still render tables, run long interactive dev or watch flows, or prompt for account, profile, or confirmation input.\n- Works best after account and project context are already configured; the repo also includes first-party MCP setup and a checked-in MCP server for teams that want that integration model.\n\n## Caveats\n- Initial auth and some setup flows are interactive, including personal access key prompts, OAuth or browser steps, and profile selection.\n- The public GitHub repo is a read-only mirror, so the source is official and current enough to review but not open to public pull requests.", "category": "http-apis", "install": "npm install -g @hubspot\/cli", "github": "https:\/\/github.com\/HubSpot\/hubspot-cli", "website": "https:\/\/developers.hubspot.com\/docs\/developer-tooling\/local-development\/hubspot-cli", "source_url": "https:\/\/developers.hubspot.com\/docs\/developer-tooling\/local-development\/hubspot-cli", "stars": 183, "language": "TypeScript", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "HubSpot" }, { "slug": "goplaces", "name": "goplaces", "description": "Google Places and Routes CLI for place search, autocomplete, details, photos, route search, and directions with JSON output.", "long_description": "goplaces is a third-party CLI and Go client for querying the Google Places API (New) and related Routes API endpoints from the shell. It focuses on read-heavy location workflows such as place discovery, candidate resolution, place details, photos, and trip-planning data.\n\n## What It Enables\n- Search for places by text, nearby coordinates, or autocomplete input, then filter by type, rating, price level, open-now status, and locale.\n- Resolve free-form locations, fetch place details with reviews or photos, and turn photo resource names into direct media URLs.\n- Get directions between addresses, place IDs, or coordinates, and search for places along a route to plan stops or compare travel modes.\n\n## Agent Fit\n- After API key setup, the commands stay non-interactive, and `--json` works across search, autocomplete, nearby, route, directions, details, photo, and resolve output.\n- Structured results plus explicit stderr pagination tokens make it easy to chain inspect-then-follow-up steps in shell scripts or agent loops.\n- Useful when an agent needs Google place and route data from the shell; the main limits are API credential setup, billing, and the fact that the tool is read-only rather than a mutation surface.\n\n## Caveats\n- Requires a Google Cloud API key and enabled Places API (New); `route` and `directions` also need the Routes API.\n- Google bills these APIs per usage, so unattended workflows should use quotas and budget alerts.", "category": "utilities", "install": "brew install steipete\/tap\/goplaces", "github": "https:\/\/github.com\/steipete\/goplaces", "website": null, "source_url": null, "stars": 182, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "google", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "pv", "name": "pv", "description": "Pipeline utility for showing transfer progress, throttling throughput, and watching data movement through pipes or files.", "long_description": "pv is a Unix pipeline utility for monitoring and shaping data as it moves between commands or files. It adds progress, rate, ETA, and transfer controls without changing the rest of the pipeline.\n\n## What It Enables\n- Show progress, throughput, bytes transferred, and ETA for long-running copy, compression, backup, disk-image, or log-processing pipelines.\n- Throttle or reshape transfers with rate limits, buffer sizing, store-and-forward, sparse output, discard mode, and read-error skipping for bulk data moves.\n- Watch file descriptors opened by another process, or query and retune a running `pv` instance with `--watchfd`, `--query`, and `--remote`.\n\n## Agent Fit\n- Fits shell loops well because it sits inline in existing pipelines and exposes direct flags for inspect and control instead of an interactive UI.\n- Machine-readable output exists, but only through `--numeric` and custom `--format` strings; default progress output is human-oriented text on stderr.\n- Best as a support primitive around data-moving commands such as `tar`, `dd`, `gzip`, or custom producers and consumers, not as a standalone service-control CLI.\n\n## Caveats\n- `--watchfd` is documented for Linux and macOS only.\n- `--remote` and `--query` require writable IPC paths such as `\/run\/user\/\/` or `$HOME\/.pv\/`.", "category": "utilities", "install": "brew install pv", "github": "https:\/\/github.com\/a-j-wood\/pv", "website": "https:\/\/ivarch.com\/p\/pv", "source_url": "https:\/\/www.ivarch.com\/programs\/pv.shtml", "stars": 178, "language": "C", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "datadog-ci", "name": "Datadog CI", "description": "Official Datadog CLI for CI\/CD test uploads, deployment events and gates, synthetic test runs, and serverless instrumentation.", "long_description": "Datadog CI is Datadog's CLI for pushing CI\/CD metadata into Datadog and for making targeted changes around test visibility, deployments, synthetic tests, and serverless instrumentation. It is mainly a pipeline companion: run it in CI or after deploys to upload reports, annotate traces, evaluate gates, or instrument supported cloud services.\n\n## What It Enables\n- Upload JUnit, coverage, SARIF, SBOM, sourcemaps, debug symbols, and git metadata so Datadog can correlate tests, code, and releases.\n- Mark deployments, correlate images or GitOps deployments to commits, evaluate deployment gates, and add custom tags, measures, or traced commands to CI jobs.\n- Run Datadog Synthetic tests from CI and instrument or uninstrument supported Lambda, Cloud Run, Azure App Services, Container Apps, and Step Functions workflows without changing app code by hand.\n\n## Agent Fit\n- Most commands are non-interactive by default and designed for CI execution, with dry-run options and clear exit behavior on flows such as `deployment gate`.\n- Some structured output exists, but much of the CLI is write-heavy upload or mutation work that logs human-readable progress instead of returning rich objects for downstream parsing.\n- Unattended use still depends on Datadog API or app keys and, for cloud instrumentation commands, valid AWS, GCP, or Azure credentials; some serverless commands also offer interactive prompt modes.\n\n## Caveats\n- This is not a general Datadog admin CLI: the repo focuses on CI\/CD, testing, release correlation, and supported instrumentation workflows, not broad Datadog resource management such as monitors.\n- Several high-value commands assume you are already in CI, inside a git repo, or authenticated to the relevant cloud provider and Datadog account.", "category": "system-monitoring", "install": "npm install -g @datadog\/datadog-ci", "github": "https:\/\/github.com\/DataDog\/datadog-ci", "website": null, "source_url": "https:\/\/datadoghq.com", "stars": 157, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Datadog" }, { "slug": "spogo", "name": "spogo", "description": "Spotify CLI for search, playback control, queue management, library updates, and playlist edits using browser cookies.", "long_description": "spogo is an unofficial Spotify CLI for search, playback control, library changes, device switching, and playlist management. It authenticates with browser cookies instead of the official developer API, then talks to Spotify web, connect, or macOS AppleScript surfaces.\n\n## What It Enables\n- Search tracks, albums, artists, playlists, shows, and episodes, then inspect detailed metadata for a specific Spotify item.\n- Start or pause playback, skip, seek, change volume, toggle shuffle or repeat, inspect queue and status, and switch the active playback device from the shell.\n- Save or remove tracks and albums, follow or unfollow artists, list your library and playlists, and create or edit playlists without opening the Spotify app.\n\n## Agent Fit\n- Global `--json` and `--plain` modes, documented exit codes, and mostly non-interactive subcommands make inspect-change-verify loops straightforward once auth is in place.\n- The command surface is broad for a single-purpose media CLI, but it still depends on a logged-in Spotify account plus an available playback target or Spotify app session.\n- Best when an agent needs direct Spotify control inside a personal automation stack; it is less useful as a general music-data tool or unattended backend integration.\n\n## Caveats\n- Auth depends on imported or pasted browser cookies, and connect playback may require the `sp_t` cookie specifically.\n- It relies on unofficial Spotify web and connect endpoints, so changes to Spotify internals or terms can break workflows.", "category": "media", "install": "brew install steipete\/tap\/spogo", "github": "https:\/\/github.com\/steipete\/spogo", "website": null, "source_url": null, "stars": 149, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "spotify", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "remindctl", "name": "remindctl", "description": "macOS Apple Reminders CLI for listing lists, filtering tasks, and creating, editing, completing, or deleting reminders.", "long_description": "remindctl is a macOS CLI for Apple Reminders built on EventKit. It gives the shell direct access to reminder lists, task filters, and reminder mutations on the local Mac.\n\n## What It Enables\n- Show reminders by time filter or list, including today, tomorrow, overdue, upcoming, completed, all, or a specific date.\n- Create reminder lists, rename or delete lists, and add reminders with due dates, notes, priorities, and list targeting.\n- Edit existing reminders, mark one or many complete, delete reminders, and check or request Reminders authorization from the terminal.\n\n## Agent Fit\n- Shared `--json` output across reads, writes, and permission checks makes it practical for inspect-then-act loops without scraping colored text.\n- The command surface is small and flag-driven, and `--plain`, `--quiet`, and `--no-input` help it fit scripts and unattended local automations.\n- It is only useful on a Mac that has Apple Reminders data and permissions, and destructive list or delete flows still prompt unless you pass `--force` or disable input.\n\n## Caveats\n- Requires macOS 14+ and Reminders access on the machine running the command.\n- This is a local Apple Reminders control layer, not a cross-platform sync service or shared team task system.", "category": "utilities", "install": "brew install steipete\/tap\/remindctl", "github": "https:\/\/github.com\/steipete\/remindctl", "website": null, "source_url": null, "stars": 140, "language": "Swift", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "apple", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "slack-cli", "name": "Slack CLI", "description": "Official Slack CLI for creating, deploying, and managing Slack platform apps, triggers, environments, and datastores.", "long_description": "Slack CLI is Slack's official command-line tool for building and operating Slack platform apps. It covers local development, deployment, app installation, triggers, collaborators, environment variables, and datastore access for Slack app projects.\n\n## What It Enables\n- Create or initialize Slack app projects, run a local dev server with file watching, and deploy app changes to the Slack Platform.\n- Install, uninstall, link, and delete apps; manage collaborators, triggers, external auth providers, and environment variables tied to a project.\n- Inspect app activity logs and read or query app datastore records, including JSON or JSON Lines output for datastore retrieval workflows.\n\n## Agent Fit\n- Global `--team`, `--app`, and `--token` flags make deploy and maintenance commands usable in scripts or CI once credentials are in place.\n- Machine-readable output is real but narrow: datastore `get`, `bulk-get`, and `query` support `--output json`, and query exports can be written as JSON Lines.\n- Best for agents that own Slack app build or deploy workflows; it is a weaker fit for general Slack administration because many commands are project-scoped and some flows still rely on prompts or Slack-mediated auth.\n\n## Caveats\n- Initial authorization often requires a slash-command ticket and challenge-code flow inside Slack, so unattended setup needs a pre-created service token.\n- Several commands are limited to apps on Slack managed infrastructure, and much of the CLI still renders human-focused output instead of structured JSON.", "category": "utilities", "install": "curl -fsSL https:\/\/downloads.slack-edge.com\/slack-cli\/install.sh | bash", "github": "https:\/\/github.com\/slackapi\/slack-cli", "website": "https:\/\/docs.slack.dev\/tools\/slack-cli\/", "source_url": null, "stars": 122, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Slack" }, { "slug": "algolia", "name": "Algolia CLI", "description": "Official Algolia CLI for searching indices, managing records and settings, and administering search resources from the terminal.", "long_description": "Algolia CLI is Algolia's command-line interface for working with search indices and the resources around them, including records, settings, rules, synonyms, API keys, dictionaries, crawler jobs, and analytics events. It gives you direct terminal access to routine search administration without going through the dashboard.\n\n## What It Enables\n- Search an index, browse records, import or update objects, and inspect index analysis or configuration from the shell.\n- List, copy, move, clear, or delete indices and manage settings, rules, synonyms, and dictionary entries in scripted workflows.\n- Inspect API keys, tail analytics events, and manage crawler runs, tests, stats, reindexing, and related crawler operations.\n\n## Agent Fit\n- Shared `--output` printers support JSON and JSONPath, and search plus record-browse commands default to JSON, which makes follow-up parsing straightforward.\n- Most commands are explicit non-interactive subcommands with stable flags, so they fit inspect\/change\/verify loops well once credentials are configured.\n- Setup and destructive actions add some friction: profile bootstrap often starts interactively, some commands require `-y\/--confirm` in non-TTY use, and crawler commands need separate crawler credentials.\n\n## Caveats\n- Requires Algolia credentials and ACL-scoped keys, and some operations only work with admin-level access.\n- `events tail` is a long-running poller tied to the correct analytics region, and crawler commands authenticate separately from the main search profile.", "category": "http-apis", "install": "brew install algolia\/algolia-cli\/algolia", "github": "https:\/\/github.com\/algolia\/cli", "website": "https:\/\/www.algolia.com\/doc\/tools\/cli", "source_url": "https:\/\/www.algolia.com\/doc\/tools\/cli", "stars": 106, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Algolia" }, { "slug": "okta", "name": "Okta CLI", "description": "Official Okta CLI for developer org signup, login, OIDC app creation, sample app bootstrapping, and basic app management.", "long_description": "Okta CLI is Okta's command line tool for setting up developer org access and wiring applications to Okta from the shell. Its scope is narrower than a full Okta admin CLI: it focuses on org signup or login, OIDC app creation, sample bootstrapping, and a few basic app or log tasks.\n\n## What It Enables\n- Register a new Okta developer org or log into an existing org and write local `~\/.okta\/okta.yaml` credentials for later CLI use.\n- Create web, SPA, native, or service OIDC apps, choose redirect and logout URIs, and write the resulting issuer and client settings into app config files or terminal output.\n- List, inspect, and delete Okta apps from the terminal, and bootstrap Okta sample projects with matching application configuration.\n\n## Agent Fit\n- The command set is explicit and there is a real `--batch` mode plus flags such as `--app-name`, `--config-file`, and `--redirect-uri`, so repeatable setup flows can be scripted once credentials already exist.\n- Automation is limited by plain-text output only: app lists, config reads, and logs do not expose a structured JSON mode for reliable follow-up parsing.\n- Works best for guided bootstrap tasks rather than unattended administration, because `register`, `login`, issuer selection, and some delete or create flows still depend on prompts or other human steps when inputs are incomplete.\n\n## Caveats\n- This is a developer-onboarding CLI, not a broad Okta admin surface for users, groups, policies, or lifecycle management.\n- `register` requires email verification and `login` requires an API token from the Okta admin console before most commands become useful.", "category": "security", "install": "brew install --cask oktadeveloper\/tap\/okta", "github": "https:\/\/github.com\/okta\/okta-cli", "website": "https:\/\/cli.okta.com\/", "source_url": "https:\/\/github.com\/okta\/okta-cli", "stars": 101, "language": "Java", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Okta" }, { "slug": "gifgrep", "name": "gifgrep", "description": "GIF search CLI and terminal browser for finding Tenor or Giphy results, downloading them, and extracting PNG stills or sheets.", "long_description": "gifgrep is a CLI for searching GIF providers from the terminal, either as pipeable search results or through an inline-preview TUI. It also includes local GIF utilities for downloading matches and turning GIFs into PNG stills or contact sheets.\n\n## What It Enables\n- Search Tenor or Giphy for reaction GIFs and emit URLs, markdown, TSV, or JSON for follow-on shell steps.\n- Download matches to `~\/Downloads` or browse them interactively with inline previews in supported terminals.\n- Extract a single PNG frame or build a contact sheet from a local GIF or remote GIF URL.\n\n## Agent Fit\n- Search commands are non-interactive, and `--json` returns stable fields such as `id`, `title`, `url`, `preview_url`, `tags`, `width`, and `height`.\n- It composes cleanly in media or publishing workflows, but the richer browsing path depends on a TTY with Kitty, Ghostty, or iTerm2 image support.\n- Best when an agent needs to fetch or transform GIF assets; it is a narrow media primitive, not a broad inspect-or-mutate system CLI.\n\n## Caveats\n- Giphy searches require `GIPHY_API_KEY`; otherwise `auto` falls back to Tenor and may use Tenor's public demo key.\n- Inline previews are terminal-dependent, and CLI thumbnails are still frames rather than full animation.", "category": "media", "install": "brew install steipete\/tap\/gifgrep", "github": "https:\/\/github.com\/steipete\/gifgrep", "website": "https:\/\/gifgrep.com\/", "source_url": null, "stars": 101, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": true, "source_type": "github", "vendor_name": null }, { "slug": "neon", "name": "Neon CLI", "description": "CLI for managing Neon Postgres projects, branches, databases, roles, and connection strings.", "long_description": "Neon CLI is the shell interface for managing Neon Postgres projects and branch-oriented database workflows. It covers project lifecycle work, branch operations, access controls, and connection setup without relying on the web console.\n\n## What It Enables\n- Create, inspect, update, delete, and recover Neon projects, then save default org or project context for follow-up commands.\n- Create, reset, restore, diff, expire, and set default branches, plus add compute and inspect long-running operations.\n- Manage databases, roles, IP allowlists, and VPC endpoint restrictions, then generate branch-specific connection strings or open `psql`.\n\n## Agent Fit\n- Global `--output json|yaml|table` support makes inspect and mutation commands straightforward to parse in scripts or follow-up agent steps.\n- API key auth, explicit IDs, and saved context files make multi-step inspect\/change\/verify loops practical.\n- Fresh setups fall back to browser OAuth, and missing org context can trigger interactive prompts, so unattended runs should provide `--api-key` and explicit scope.\n\n## Caveats\n- Default auth opens a browser, and CI explicitly rejects interactive auth.\n- When org context is missing, some project commands can prompt you to choose and optionally save an organization.", "category": "databases", "install": "brew install neonctl", "github": "https:\/\/github.com\/neondatabase\/neonctl", "website": "https:\/\/neon.com\/docs\/reference\/neon-cli", "source_url": null, "stars": 100, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Neon" }, { "slug": "sonoscli", "name": "sonoscli", "description": "Sonos speaker control CLI for discovery, playback, grouping, queue management, favorites, scenes, and Spotify handoff.", "long_description": "sonoscli is a local-network Sonos control CLI for discovering speakers, reading playback state, and changing what a room or group is doing. It covers day-to-day speaker control plus higher-level operations like queue management, favorites, scenes, and Sonos-side music-service search.\n\n## What It Enables\n- Discover speakers, inspect playback and group state, and watch live transport or rendering events from the shell.\n- Play, pause, skip, change volume or mute, switch to TV or line-in, and regroup rooms without opening the Sonos app.\n- List and manipulate queues, open favorites, save and reapply room scenes, and search linked music services or Spotify for playable items.\n\n## Agent Fit\n- Global `--format plain|json|tsv` support plus JSON responses for many action commands make it workable in scripts and follow-up parsing.\n- Coordinator-aware targeting, discovery, and topology handling reduce Sonos-specific edge cases an agent would otherwise need to reimplement.\n- It fits best for local automations on the same LAN; linked-service auth, firewall prompts for `watch`, and speaker reachability limit unattended use.\n\n## Caveats\n- Requires access to the same local network as the Sonos system, with speakers reachable on TCP port `1400`.\n- `watch` opens a local callback server, and some SMAPI searches need a one-time DeviceLink or AppLink flow through the Sonos-linked service.", "category": "utilities", "install": "brew install steipete\/tap\/sonoscli", "github": "https:\/\/github.com\/steipete\/sonoscli", "website": null, "source_url": null, "stars": 100, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": "sonos", "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "exoscale-cli", "name": "Exoscale CLI", "description": "Official Exoscale CLI for managing compute, DNS, storage, Kubernetes, database, IAM, and AI inference resources.", "long_description": "Exoscale CLI is Exoscale's official shell interface for provisioning and operating cloud resources across compute, networking, storage, database, IAM, Kubernetes, and newer dedicated inference services. It is a general control plane CLI, not just a thin wrapper around one product area.\n\n## What It Enables\n- Create, inspect, update, and delete Exoscale infrastructure such as instances, load balancers, block storage, private networks, DNS zones and records, object storage buckets, and IAM resources.\n- Manage higher-level platform services including SKS Kubernetes clusters and node pools, DBaaS services and users, and dedicated inference models or deployments.\n- Generate kubeconfig or ExecCredential data, fetch service logs, and script follow-up shell steps against resources in the right account and zone.\n\n## Agent Fit\n- Global JSON and text-template output modes make it practical to inspect state, pipe results, and feed follow-up commands in shell or CI workflows.\n- Most day-two resource operations are direct Cobra subcommands with predictable flags, aliases, exit behavior, and `--force` paths that suit unattended automation once credentials exist.\n- The rough edges are setup and some live workflows: initial `exo config` wants a TTY, many destructive commands prompt by default, and a few outputs like raw logs or kubeconfig are better for handoff than structured parsing.\n\n## Caveats\n- You need Exoscale API credentials and account or zone context before most commands are useful, and the guided config flow is explicitly interactive.\n- Some commands emit domain-specific plaintext rather than structured objects, especially for logs, kubeconfig material, and human-oriented status views.", "category": "cloud", "install": "brew tap exoscale\/tap && brew install exoscale-cli", "github": "https:\/\/github.com\/exoscale\/cli", "website": "https:\/\/community.exoscale.com\/reference\/cli\/", "source_url": "https:\/\/community.exoscale.com\/product\/cli\/", "stars": 90, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Exoscale" }, { "slug": "render", "name": "Render CLI", "description": "Render CLI for managing services, deploys, logs, databases, workflows, and blueprint validation.", "long_description": "Render CLI is Render's command-line client for operating services, datastores, and workflow services on the platform. It combines a default Bubble Tea TUI with non-interactive commands for deploys, logs, jobs, database access, blueprint validation, and some early-access storage workflows.\n\n## What It Enables\n- List services, datastores, projects, workspaces, deploys, jobs, environments, workflow versions, tasks, and task runs from the shell.\n- Trigger deploys, restarts, one-off jobs, workflow releases, and workflow task runs, then wait for completion and inspect logs or returned resource state.\n- Open `psql`, `pgcli`, `redis-cli`, or SSH sessions, validate `render.yaml` blueprints before deploys, and upload or fetch objects in Render's early-access object storage.\n\n## Agent Fit\n- Many read and write commands support `--output json|yaml|text`, `--confirm`, and API-key auth, which makes inspect-change-verify loops workable in CI and agent scripts.\n- Structured responses plus `--wait` flows for deploys and workflow releases make it practical to trigger an action, poll, and branch on success or failure without scraping the dashboard.\n- The automation surface is mixed rather than perfect: the CLI defaults to a fullscreen TUI, non-TTY mode falls back to text unless you set output explicitly, and session-oriented commands like SSH stay human-interactive.\n\n## Caveats\n- Useful unattended usage usually requires explicit `--output json` or `RENDER_OUTPUT=json`; auto mode does not default to JSON.\n- You still need Render auth and workspace context, and some capabilities are intentionally terminal-session workflows rather than machine-first APIs.", "category": "cloud", "install": "brew install render", "github": "https:\/\/github.com\/render-oss\/cli", "website": "https:\/\/render.com\/docs\/cli", "source_url": "https:\/\/render.com\/docs\/cli", "stars": 79, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": true, "source_type": "github", "vendor_name": "Render" }, { "slug": "fauna-shell", "name": "Fauna Shell", "description": "Official Fauna CLI for running FQL queries, managing databases and schema, creating exports, and starting local Fauna containers.", "long_description": "Fauna CLI is Fauna's official command line for querying databases, managing database and schema state, creating exports, and working against a local Fauna container. It gives shell access to both day-to-day FQL work and admin flows that would otherwise go through the dashboard or HTTP APIs.\n\n## What It Enables\n- Run FQL from inline strings, files, stdin, or an interactive REPL, and write results to stdout or files.\n- Create, list, and delete databases, then pull, diff, push, commit, or abandon `.fsl` schema changes from local directories.\n- Create, inspect, and wait on export jobs to S3, and start a local Fauna container with an optional database and schema.\n\n## Agent Fit\n- Real structured output exists: `query` supports `--json` and `--format json`, while database and export commands also emit JSON on supported subcommands.\n- Most operations are regular flags-and-stdout commands, with file and stdin support that fits inspect, change, and verify loops.\n- Authentication and some schema flows are less hands-off: `fauna login` is browser-based by default, and `schema push` or `schema commit` prompt unless run with `--no-input`.\n\n## Caveats\n- The project is branded as \"Fauna CLI\" in the README, while `fauna-shell` is the package and repo name; the current directory entry uses the older naming.\n- Output formats are uneven across subcommands, with some admin and schema flows defaulting to YAML, TSV, or human-readable diffs rather than JSON.", "category": "databases", "install": "npm install -g fauna-shell", "github": "https:\/\/github.com\/fauna\/fauna-shell", "website": "https:\/\/docs.fauna.com\/fauna\/current\/build\/cli\/v4\/", "source_url": "https:\/\/docs.faunadb.org\/fauna\/current\/build\/cli\/", "stars": 77, "language": "JavaScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Fauna" }, { "slug": "kraken-cli", "name": "Kraken CLI", "description": "Official Kraken CLI for market data, account operations, spot and futures trading, funding, and paper trading.", "long_description": "Kraken CLI is Kraken's command-line client for public market data, private account operations, spot and futures trading, funding flows, WebSocket streams, and a local paper-trading sandbox. The repo is unusually agent-oriented, with machine-readable command contracts and workflow skills checked in alongside the core CLI.\n\n## What It Enables\n- Read public ticker, order book, OHLC, trade, and spread data, or subscribe to spot and futures WebSocket feeds from the shell.\n- Inspect balances, orders, ledgers, positions, funding, earn allocations, and subaccounts, then place, amend, or cancel spot and futures orders without building directly on the Kraken APIs.\n- Test trading workflows against live prices with `kraken paper` before promoting the same patterns to a live account.\n\n## Agent Fit\n- `-o json`, JSON error envelopes on stdout, stderr-only diagnostics, and non-zero exit codes make one-shot commands easy to parse and chain in automation.\n- Public reads, private account queries, and paper trading all work as non-interactive subcommands once credentials and flags are set, so agents can inspect, decide, act, and verify in the shell.\n- The main limit is risk, not ergonomics: dangerous commands can move real money, some human entry points are interactive, and live use needs tighter approval boundaries even though the repo also includes a built-in MCP server and many workflow skills.\n\n## Caveats\n- Live orders, withdrawals, and transfers are real account mutations; use paper trading, `--validate`, limited-permission API keys, and `cancel-after` before unattended use.\n- Default output is table and some modes are interactive or streaming (`setup`, `shell`, `ws`, `mcp`), so automation should request JSON and stick to one-shot commands unless it is prepared for those runtimes.", "category": "trading-crypto", "install": "curl --proto '=https' --tlsv1.2 -LsSf https:\/\/github.com\/krakenfx\/kraken-cli\/releases\/latest\/download\/kraken-cli-installer.sh | sh", "github": "https:\/\/github.com\/krakenfx\/kraken-cli", "website": null, "source_url": "https:\/\/github.com\/krakenfx\/kraken-cli", "stars": 60, "language": "Rust", "has_mcp": true, "has_skill": true, "has_json": true, "brand_icon": "", "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Kraken" }, { "slug": "ordercli", "name": "ordercli", "description": "Food delivery CLI for checking Foodora and Deliveroo order status and history, with Foodora reorder support.", "long_description": "ordercli is an unofficial CLI for inspecting Foodora and Deliveroo delivery state from the shell. It focuses on active orders, past order history, and a Foodora-specific reorder path that rebuilds a cart from a previous order.\n\n## What It Enables\n- Check active Foodora orders, poll delivery status, and inspect a single tracked order from the terminal.\n- List Foodora past orders, show itemized historical order details as JSON, and rebuild a previous Foodora order into your cart when you explicitly confirm.\n- Inspect Deliveroo active orders either through bearer-token API access or by extracting a recent public status URL from local browser history, and list Deliveroo history when tokens are available.\n\n## Agent Fit\n- Provider-first subcommands and ordinary flags make the CLI easy to script once auth and region config are in place.\n- Real JSON output exists for Foodora `history show`, confirmed Foodora reorders, Deliveroo history, and Deliveroo active-order status, so agents do not always need to parse human text.\n- Authentication is the limiting factor: MFA, Cloudflare, Chrome cookie import, browser-history lookup, and Node\/Playwright browser runs make unattended use fragile.\n\n## Caveats\n- This is an unofficial client against private or semi-private service surfaces, so provider changes or bot protection can break flows without notice.\n- Deliveroo support is still partial: `history` requires a bearer token, and one supported `orders` path depends on local Atlas or Chrome history plus headless Chromium.", "category": "utilities", "install": "go install github.com\/steipete\/ordercli@latest", "github": "https:\/\/github.com\/steipete\/ordercli", "website": null, "source_url": null, "stars": 55, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "upctl", "name": "UpCloud CLI", "description": "Official UpCloud CLI for managing servers, storage, networking, Kubernetes, databases, object storage, and related UpCloud resources.", "long_description": "UpCloud CLI is UpCloud's official command-line client for provisioning and operating UpCloud infrastructure. It covers core compute and networking resources plus managed services such as Kubernetes, databases, object storage, and load balancers.\n\n## What It Enables\n- Create, inspect, start, stop, modify, relocate, and delete servers, storages, IPs, networks, routers, firewalls, and server groups.\n- Provision and operate managed services including Kubernetes clusters, node groups, managed databases, load balancers, file storage, gateways, and object storage users, buckets, access keys, and policies.\n- Export kubeconfig or audit logs, inspect account limits or permissions, and clean up whole environments with `all list` and `all purge` workflows.\n\n## Agent Fit\n- Global `-o json` or `-o yaml`, stable exit codes, and flag-heavy commands make inspect-parse-act loops workable in shell automation.\n- Examples are explicitly written as scripts that parse JSON with `jq`, and many create or delete commands offer `--wait` support for convergent workflows.\n- Best once credentials are already configured, because useful runs depend on UpCloud account context and often combine `upctl` with tools like `kubectl`, `ssh`, or S3 clients.\n\n## Caveats\n- Requires UpCloud credentials and account permissions, and most commands operate on billable cloud resources.\n- Stack commands are explicitly marked experimental, and some common workflows depend on companion tools outside the CLI.", "category": "cloud", "install": "brew tap UpCloudLtd\/tap && brew install upcloud-cli", "github": "https:\/\/github.com\/UpCloudLtd\/upcloud-cli", "website": "https:\/\/upcloudltd.github.io\/upcloud-cli\/", "source_url": "https:\/\/upcloudltd.github.io\/upcloud-cli\/", "stars": 51, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "UpCloud" }, { "slug": "eightctl", "name": "eightctl", "description": "Unofficial Eight Sleep CLI for pod control, schedules, alarms, sleep metrics, and device data.", "long_description": "eightctl is an unofficial Go CLI for controlling Eight Sleep pods and pulling sleep or device data through the same cloud endpoints the mobile app uses. It covers direct controls like temperature and power plus higher-level automations such as schedules, alarms, and a local daemon.\n\n## What It Enables\n- Turn the pod on or off, set temperature levels, inspect current status, and manage cloud schedules or alarms without using the mobile app.\n- Export sleep days, date ranges, presence, metrics, autopilot history, and household or device details for reporting and follow-up automation.\n- Control extra product features exposed by the service, including base positions, audio playback, temperature modes, and YAML-driven recurring routines.\n\n## Agent Fit\n- Global `--output table|json|csv` and `--fields` filtering make status, schedule, sleep, and metrics commands easy to parse in scripts.\n- Most commands are single-shot Cobra subcommands with flags, env-based auth, and clear exit behavior, so they fit inspect, change, and verify loops once credentials are configured.\n- The weak point is upstream stability: the CLI depends on undocumented, rate-limited cloud APIs, and the repo does not ship built-in MCP or skill support beyond the raw command surface.\n\n## Caveats\n- Everything depends on private Eight Sleep cloud endpoints and baked-in app credentials, so vendor-side API changes can break workflows without notice.\n- The README labels the project WIP and notes that live verification is currently hampered by Eight Sleep API throttling on the maintainer's test account.", "category": "utilities", "install": "GO111MODULE=on go install github.com\/steipete\/eightctl\/cmd\/eightctl@latest", "github": "https:\/\/github.com\/steipete\/eightctl", "website": null, "source_url": null, "stars": 51, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "mergiraf", "name": "Mergiraf", "description": "Syntax-aware merge driver for resolving Git conflicts structurally across supported code and config formats.", "long_description": "Mergiraf is a syntax-aware merge driver for resolving version-control conflicts in supported code and data files. It is designed to plug into Git directly and is also documented for Jujutsu workflows through `jj resolve --tool mergiraf`.\n\n## What It Enables\n- Register as a Git merge driver so merges, rebases, cherry-picks, and reverts can auto-resolve supported files structurally instead of falling back immediately to plain text conflicts.\n- Run `mergiraf solve` on an already conflicted file to rewrite it with fewer or narrower conflict markers, or print the attempted resolution to stdout.\n- List supported languages, compare Mergiraf's result against a line-based merge with `review`, and package a failing merge into a reproducible zip via `report`.\n\n## Agent Fit\n- Commands operate on explicit files, return meaningful exit codes, and can run non-interactively inside merge, rebase, or CI workflows.\n- The automation surface is narrow and text-first: there is no JSON output, no remote repository inspection, and most outputs are rewritten files, diffs, or logs.\n- Best used as a focused primitive inside Git or Jujutsu conflict-resolution flows rather than as a general replacement for tools like `git` or `jj`.\n\n## Caveats\n- Best results depend on supported languages and `diff3` conflict style; unknown or unparsable files fall back to line-based merging.\n- Jujutsu users should invoke it through `jj resolve --tool mergiraf`; `mergiraf solve` does not understand Jujutsu's native conflict marker format.", "category": "github", "install": "cargo install --locked mergiraf", "github": "https:\/\/github.com\/qundao\/mirror-mergiraf", "website": "https:\/\/mergiraf.org\/", "source_url": "https:\/\/codeberg.org\/mergiraf\/mergiraf", "stars": 46, "language": "Rust", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": false, "is_tui": false, "source_type": "github", "vendor_name": null }, { "slug": "upstash-cli", "name": "Upstash CLI", "description": "Official Upstash CLI for provisioning, inspecting, and administering Upstash Redis databases and teams.", "long_description": "Upstash CLI is Upstash's official command-line interface for control-plane operations on Upstash Redis and account teams. It is built for managing database lifecycle, credentials, placement, and team membership from the shell or CI.\n\n## What It Enables\n- Create, list, inspect, and delete Upstash Redis databases, including region selection and replication-related settings during provisioning.\n- Check database details and usage stats, rename databases, reset passwords, and move a database to another team without using the web console.\n- Create and delete teams, list team members, and invite or remove members for account-level administration.\n\n## Agent Fit\n- The Redis and team command groups support `--json`, and `redis stats` returns structured JSON by default, so follow-up parsing and verification are straightforward.\n- Auth can come from flags, environment variables, or a saved config file, which keeps scripted runs simple once management API credentials are in place.\n- Useful for agents that provision or administer Upstash Redis, but a weaker fit if you need QStash, Vector, or older Kafka workflows because those commands are not present in the current source.\n\n## Caveats\n- Human-readable tables are still the default for many commands, so automation should opt into `--json` consistently.\n- Some commands can fall back to interactive prompts when flags are omitted, and the CLI requires Upstash management API credentials before any remote action.", "category": "databases", "install": "npm install -g @upstash\/cli", "github": "https:\/\/github.com\/upstash\/cli", "website": "https:\/\/upstash.com\/docs\/devops\/cli\/overview", "source_url": "https:\/\/upstash.com\/docs\/devops\/cli\/overview", "stars": 24, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Upstash" }, { "slug": "gcloud", "name": "gcloud CLI", "description": "Official Google Cloud CLI for managing Google Cloud resources, IAM, configs, deployments, and service APIs from the shell.", "long_description": "Google Cloud CLI is Google's command line for working with Google Cloud projects, configurations, and service APIs across compute, storage, networking, IAM, deployments, and many other products. It gives one shell surface for both resource inspection and change operations instead of stitching together raw REST calls.\n\n## What It Enables\n- Create, inspect, update, and delete Google Cloud resources such as VM instances, storage buckets, IAM settings, network objects, and service-specific resources from one CLI.\n- Switch projects and configurations, manage authentication context, and run service operations or deployments without leaving the terminal.\n- Filter and format resource data for follow-up shell steps, CI jobs, or agent inspect\/change\/verify loops.\n\n## Agent Fit\n- Global formatting and filtering features, including `--format=json`, make command results easy to parse and chain into scripts.\n- `--quiet` and prompt-disabling settings help with unattended execution, but initial auth often uses browser-based login and should be replaced with service accounts or impersonation for automation.\n- Good fit when an agent needs broad first-party Google Cloud coverage from one tool; MCP support exists in alpha and beta command groups, but the normal CLI surface is the primary value.\n\n## Caveats\n- The command surface is huge and mixes GA, beta, and alpha groups, so stable automation should pin commands, flags, project, region, and output explicitly.\n- The checked-out GitHub repo is an unofficial mirror, so official Google Cloud docs are the safer source of truth for install and product guidance.", "category": "cloud", "install": "curl https:\/\/sdk.cloud.google.com | bash", "github": "https:\/\/github.com\/google-cloud-sdk-unofficial\/google-cloud-sdk", "website": "https:\/\/cloud.google.com\/sdk\/gcloud", "source_url": "https:\/\/cloud.google.com\/sdk\/gcloud", "stars": 19, "language": "Python", "has_mcp": true, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Google Cloud" }, { "slug": "opensea", "name": "OpenSea CLI", "description": "OpenSea CLI for querying NFT collections, NFTs, listings, offers, events, accounts, tokens, and swap quotes.", "long_description": "OpenSea CLI is the official command-line client for OpenSea's API. It gives you shell access to NFT metadata, marketplace activity, account lookups, token data, and swap quotes, with one metadata-refresh action for NFTs.\n\n## What It Enables\n- Inspect collections, NFT assets, contracts, account holdings, and collection stats or traits across OpenSea-supported chains.\n- Monitor marketplace state by listing offers, best listings, sales, transfers, mints, and search results across collections, NFTs, tokens, and accounts.\n- Pull trending or top token data, request swap quotes, and trigger NFT metadata refresh requests when OpenSea's index needs an update.\n\n## Agent Fit\n- JSON is the default output, commands are flag-driven, and failures return structured JSON plus distinct exit codes, which fits inspect-parse-retry loops well.\n- Cursor pagination, field filtering, retries, and a health check make it practical to script larger read-heavy workflows without scraping the website.\n- The surface is narrower than the full OpenSea product: agents can inspect and refresh metadata, but they cannot manage listings or execute trades through this CLI.\n\n## Caveats\n- Useful operation requires an OpenSea API key.\n- Most commands are read-only wrappers around the OpenSea API, so this is stronger for monitoring and enrichment than for marketplace mutation.", "category": "utilities", "install": "npm install -g @opensea\/cli", "github": "https:\/\/github.com\/ProjectOpenSea\/opensea-cli", "website": "https:\/\/docs.opensea.io\/reference\/cli-overview", "source_url": null, "stars": 6, "language": "TypeScript", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "OpenSea" }, { "slug": "acli", "name": "Atlassian CLI", "description": "Official Atlassian CLI for Jira and Confluence workflows from the terminal.", "long_description": null, "category": "dev-tools", "install": "See install docs", "github": null, "website": "https:\/\/developer.atlassian.com\/cloud\/acli\/", "source_url": "https:\/\/developer.atlassian.com\/cloud\/acli\/", "stars": 0, "language": null, "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": "atlassian", "is_official": true, "is_tui": false, "source_type": "vendor", "vendor_name": "Atlassian" }, { "slug": "basecamp", "name": "Basecamp CLI", "description": "Official Basecamp CLI for agent-friendly Basecamp workflows and account operations from the terminal.", "long_description": null, "category": "dev-tools", "install": "curl -fsSL https:\/\/basecamp.com\/install-cli | bash", "github": null, "website": "https:\/\/basecamp.com\/agents", "source_url": "https:\/\/basecamp.com\/agents", "stars": 0, "language": null, "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "vendor", "vendor_name": "Basecamp" }, { "slug": "crush", "name": "Crush", "description": "AI CLI agent focused on task execution, coding assistance, and terminal-native workflows for developers.", "long_description": null, "category": "agent-harnesses", "install": "curl -fsSL https:\/\/crush.dev\/install.sh | bash", "github": null, "website": "https:\/\/crush.dev", "source_url": "https:\/\/crush.dev", "stars": 0, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "vendor", "vendor_name": "Crush" }, { "slug": "forgejo-cli", "name": "Forgejo CLI", "description": "Command-line interface for Forgejo for repository, issue, and pull request workflows in self-hosted Git forges.", "long_description": null, "category": "github", "install": "brew install forgejo\/tap\/forgejo-cli", "github": "", "website": "https:\/\/codeberg.org\/forgejo\/forgejo-cli", "source_url": "https:\/\/codeberg.org\/forgejo\/forgejo-cli", "stars": 0, "language": "Go", "has_mcp": false, "has_skill": false, "has_json": true, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Forgejo" }, { "slug": "screen", "name": "GNU Screen", "description": "Classic terminal multiplexer for persistent sessions, detach\/reattach workflows, and remote shell management.", "long_description": null, "category": "shell-utilities", "install": "brew install screen", "github": null, "website": "https:\/\/www.gnu.org\/software\/screen\/", "source_url": "https:\/\/www.gnu.org\/software\/screen\/", "stars": 0, "language": "C", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "vendor", "vendor_name": "GNU" }, { "slug": "ldcli", "name": "LaunchDarkly CLI", "description": "Official LaunchDarkly CLI for feature flag, project, and environment workflows from the terminal.", "long_description": null, "category": "dev-tools", "install": "brew install launchdarkly\/tap\/ldcli", "github": null, "website": "https:\/\/launchdarkly.com\/docs\/home\/getting-started\/ldcli", "source_url": "https:\/\/launchdarkly.com\/docs\/home\/getting-started\/ldcli", "stars": 0, "language": null, "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "vendor", "vendor_name": "LaunchDarkly" }, { "slug": "sf", "name": "Salesforce CLI", "description": "Official Salesforce CLI for org management, metadata operations, deploy flows, and automation.", "long_description": null, "category": "dev-tools", "install": "See install docs", "github": null, "website": "https:\/\/developer.salesforce.com\/tools\/salesforcecli", "source_url": "https:\/\/developer.salesforce.com\/tools\/salesforcecli", "stars": 0, "language": null, "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "vendor", "vendor_name": "Salesforce" }, { "slug": "shopify-cli", "name": "Shopify CLI", "description": "Official Shopify CLI for apps, themes, Hydrogen storefronts, and local development workflows.", "long_description": null, "category": "dev-tools", "install": "npm install -g @shopify\/cli@latest", "github": null, "website": "https:\/\/shopify.dev\/docs\/api\/shopify-cli", "source_url": "https:\/\/shopify.dev\/docs\/api\/shopify-cli", "stars": 0, "language": null, "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": "shopify", "is_official": true, "is_tui": false, "source_type": "vendor", "vendor_name": "Shopify" }, { "slug": "tinybird-cli", "name": "Tinybird CLI", "description": "CLI for managing Tinybird data sources, pipes, deployments, and local development workflows.", "long_description": null, "category": "databases", "install": "curl -fsSL https:\/\/tinybird.co | sh", "github": "", "website": "https:\/\/www.tinybird.co\/docs\/forward\/dev-reference\/tb-cli", "source_url": "https:\/\/www.tinybird.co\/docs\/forward\/dev-reference\/tb-cli", "stars": 0, "language": "Python", "has_mcp": false, "has_skill": false, "has_json": false, "brand_icon": null, "is_official": true, "is_tui": false, "source_type": "github", "vendor_name": "Tinybird" } ] }