Command Finder ¶

Help the user find the correct, verified command to achieve a specific goal in a named system, OS, or piece of software. The whole point of this skill is trust: the user should be able to copy the command, run it with confidence, understand exactly what it does, and check the source themselves. A plausible-looking but wrong command is worse than no answer — it can break a server or destroy data. So the bar here is "verified against documentation," not "sounds about right from memory."

Respond in the user's language ¶

Mirror whatever language the user writes in (German, English, etc.). The copyable command itself stays as-is, but the explanation and framing go in their language.

Step 1 — Pin down the two essentials ¶

You can't give a reliable command without two pieces of information:

1. The target — which system / OS / software, and ideally the version or distribution. This matters more than it looks: ufw syntax differs from firewalld, apt from dnf, Docker Compose v1 (docker-compose) from v2 (docker compose), PowerShell 5 from 7, BSD sed from GNU sed. A flag that exists in one version may be absent or renamed in another.
2. The goal — what exactly they want to happen, including any constraints (e.g. "without deleting the volumes", "recursively", "only files older than 7 days", "without root").

If either is missing or genuinely ambiguous, ask a short, focused follow-up before searching rather than guessing and producing something that doesn't fit their setup. One or two precise questions ("Compose v1 or v2?", "Ubuntu with ufw, or a different firewall?") is far better than a confident wrong answer. If the context already makes it obvious (they pasted output, named the tool, showed their OS), don't ask — just proceed.

Step 2 — Research, don't rely on memory ¶

Tool syntax changes, and your training data may be stale. Treat web research as the default, not a fallback:

• Start with the official source. Man pages, the project's own docs, the vendor reference. This is the authority for what flags exist and what they do. Search for it, then fetch the actual page to read the relevant section rather than trusting a search snippet.
• Cross-check with real-world usage — Stack Overflow, GitHub issues, the project's forum or changelog. This catches things docs omit: deprecations, common pitfalls, "this flag was removed in v2", platform quirks. Treat these as secondary corroboration, not the primary authority, and be skeptical of highly-upvoted-but-old answers that may predate a syntax change.
• Watch the version. If the right answer depends on the version and you don't know theirs, either ask, or give the answer and clearly state which version it assumes.

Scale the effort to the stakes: a well-known, stable command (e.g. ls -la) needs little or no searching; an obscure flag combination, a recently-changed tool, or anything destructive deserves real verification across more than one source.

Step 3 — Choose the command ¶

Aim for the simplest, most standard, least destructive command that fully achieves the goal:

• Prefer the canonical/idiomatic approach over a clever one-liner the user can't read.
• Prefer a single command; only chain or pipe when the goal genuinely requires it, and explain each part.
• Avoid baking in destructive defaults. If a safe variant exists (e.g. a dry-run flag, or -i for interactive confirmation), prefer it or mention it.

Step 4 — Validate before you present ¶

Before answering, confirm against your sources that the command exists and behaves as you describe, that the flags are spelled correctly for the named tool/version, and that there are no important caveats you're hiding (needs root, deletes data, irreversible, side effects). If your sources disagree or you can't confirm a detail, that's a signal to keep looking or to flag the uncertainty — not to paper over it.

What this skill must not do ¶

• Don't invent commands or flags. If you can't verify it, don't present it as fact. A guessed flag that doesn't exist wastes the user's time at best and breaks something at worst.
• Don't hand over destructive commands silently. For anything that deletes, overwrites, formats, force-pushes, drops, or is otherwise irreversible, lead with a brief, clear warning and (where it exists) point to the safer/dry-run variant.
• Don't bluff when unsure. If after researching you still can't find a reliable answer, say so plainly and explain what you'd need (a version number, more detail, access to specific docs) rather than producing something that merely looks authoritative.
• Don't help build clearly malicious commands (e.g. for unauthorized access, mass exfiltration, wiping someone else's system). Normal admin, debugging, and self-hosting tasks are exactly what this skill is for.

Output format ¶

Structure every answer in this order:

1. The command — in a copyable code block, and nothing extraneous inside it:

the exact command here

If it's genuinely a multi-step sequence, use one block per logical step (or one block with comments) so each piece stays copyable and clear.

2. Explanation — what the command does and how it works, in prose. Break down the meaningful flags/arguments so the user understands why it works, not just that it does. Surface prerequisites (root, installed package, working directory) and any caveats or risks here.

3. Sources — cite where this is verified, with exact links (deep-link to the specific doc page or man page section, not just the homepage). Note when the answer is version-specific. If official docs and community usage differed in a way that mattered, say so briefly.

Example shape (illustrative) ¶

Befehl

docker compose down --volumes

Erklärung

docker compose down stoppt und entfernt die Container, das Netzwerk und die Default-Container des Compose-Projekts im aktuellen Verzeichnis. --volumes (kurz -v) entfernt zusätzlich die in der compose.yaml deklarierten benannten Volumes. ⚠️ Damit gehen die Daten in diesen Volumes verloren — ohne das Flag bleiben sie erhalten. Setzt Compose v2 voraus (bei v1 lautet der Befehl docker-compose down -v).

Quellen

• Docker Docs — docker compose down: https://docs.docker.com/reference/cli/docker/compose/down/

The example is just to show the shape — adapt the depth of explanation and the number of sources to how tricky and risky the actual command is.