The Sysadmin Prompt Cheat Sheet — AI Commands That Actually Work
Copy-paste prompts for sysadmin work with Claude or any LLM: explain commands, write scripts, triage logs, review configs, convert Bash to PowerShell.
Most "prompt engineering" advice is written for marketing copy. Sysadmin work has different failure modes: the model guesses your distro, invents a flag, or hands you a command that's correct on a different box. These are the prompt shapes I keep reusing because they stop exactly those failures.
TL;DR: every useful sysadmin prompt has the same four parts.
Context: OS + version, shell, what's installed, what this box does.
Task: one concrete thing.
Constraints: read-only first / no new packages / must be idempotent / etc.
Output: exact shape you want back, plus "list your assumptions".
Copy the blocks below, fill the brackets. They work with Claude (that's what I use, mostly via the CLI) and they work fine with local models too — see Ollama for sysadmins if your data can't leave the box.
Rule zero: never paste secrets
Before any of this: whatever you paste goes to an API. Strip IPs, hostnames, tokens, passwords, customer names first. The sed redaction pipe in my log triage post is the one I use. If the data is regulated, use a local model or don't do it.
1. Explain a command before running it
For the one-liner you found on a forum at 1am.
Explain this command piece by piece. For each flag say what it does.
Then tell me: what does it change on the system, is it reversible,
and what's the worst case if I run it on the wrong host?
[paste command]
The "worst case on the wrong host" line is the whole value. It turns a summary into a risk check.
2. Write a script with guardrails
Linux version:
Write a bash script for [Ubuntu 24.04].
Task: [what it does].
Constraints: set -euo pipefail, quote all variables, no new packages,
a --dry-run flag that prints actions instead of running them,
idempotent (safe to run twice), log to stderr.
Output: the script, then a list of assumptions you made about the system.
Windows version:
Write a PowerShell script for [Windows PowerShell 5.1 on Windows Server 2022].
Task: [what it does].
Constraints: CmdletBinding with SupportsShouldProcess, parameters instead
of hardcoded paths, no aliases, no modules except [list], Write-Verbose for progress.
Output: the script, then a list of assumptions.
The PowerShell side has its own post with the full review loop: how I use Claude for PowerShell scripts.
3. Log triage
These are [nginx error log / journalctl -u X -p err] lines from [time window].
Group them by likely root cause. For the top 3: one-line summary,
severity (critical/high/low), and the exact next command to confirm it.
If a cause is a guess, say so. Don't restate the log.
[paste redacted slice]
Pull the slice first — --since, -p err, -u unit — then send it. Never the whole file.
4. Review a config file
Review this [sshd_config / nginx server block / PalWorldSettings.ini].
Context: [what the server does, what's exposed to the internet].
List: (1) actual mistakes, (2) security weaknesses, (3) style nits —
in that order, separately. For each, quote the line and give the fix.
Don't rewrite the whole file.
Splitting mistakes from nits matters. Otherwise the one real problem drowns in twelve suggestions about comment formatting. For SSH specifically, cross-check against my SSH hardening checklist — the model's opinion is a second pair of eyes, not the standard.
5. Write a systemd unit
Write a systemd service unit for [binary/script path].
It runs as user [x], working dir [y], needs network up first,
should restart on failure but not loop forever if it crashes on start.
Add basic sandboxing (ProtectSystem, PrivateTmp, NoNewPrivileges)
only where it won't break [what the service needs to write].
Explain each directive in one line after the unit.
The "won't break what it needs to write" part matters — over-eager sandboxing (ProtectSystem=strict without ReadWritePaths=) is a classic way to get a unit that starts and then fails on its first write. Background: systemd service unit files.
6. Firewall rules
I run [services + ports] on [Ubuntu with UFW / Windows Server firewall].
Admin access only from [VPN range]. Everything else public on [ports].
Give me the exact commands in the order to run them so I don't lock
myself out over SSH. Mark the one I must run last.
"In the order so I don't lock myself out" is the important constraint. Compare with UFW firewall rules on Ubuntu before running.
7. Translate between Bash and PowerShell
Convert this [bash → PowerShell 5.1 / PowerShell → bash].
Keep behaviour identical, including exit codes and error handling.
Where there's no direct equivalent, say so instead of approximating silently.
[paste script]
"Say so instead of approximating" — otherwise you get something that looks equivalent and quietly drops set -e semantics.
8. "Why is this broken" with real evidence
Symptom: [what's wrong, since when, what changed].
I've already checked: [list].
Here's the output of [commands you ran].
Give me the 3 most likely causes ranked, and for each the single
command that would confirm or rule it out. Don't suggest fixes yet.
"Don't suggest fixes yet" keeps it in diagnosis mode. Jumping straight to fixes is how you end up restarting things until the problem disappears and you never learn what it was. If you want the model to gather that evidence itself instead of you pasting it, that's what an MCP server with read-only tools is for.
9. Write the post-incident notes
Here are my raw notes and the commands I ran during an incident.
Turn them into a short write-up: timeline, root cause, what fixed it,
what to change so it doesn't happen again. Keep my wording where it's
factual. Don't invent anything that's not in the notes — mark gaps as [unknown].
The [unknown] instruction is the one that keeps it honest. Without it, gaps get filled with plausible fiction.
10. Regex and one-liners
I need a [grep -E / sed -E / PowerShell -match] pattern that matches [x]
but not [y]. Here are 5 lines that should match and 5 that shouldn't:
[examples]
Give the pattern and explain it token by token.
Examples in, pattern out. Then actually test it against the examples — that takes ten seconds and catches the cases where it doesn't.
Gotcha: the model doesn't know your box
It knows Ubuntu in general, not your Ubuntu. Package versions, which init system, whether ufw or nftables is in charge, what's in /etc — it guesses. That's why every template starts with context and ends with "list your assumptions". Read the assumptions first. Wrong assumption = wrong answer, no matter how clean the code looks.
Gotcha: invented flags and cmdlets
Sometimes the answer uses a flag that sounds right and doesn't exist, or existed in an older version. Verify before you run:
man <cmd> # or: <cmd> --help | grep -- '--flag'
Get-Command <Cmdlet> -Syntax
Five seconds. Cheaper than finding out in production.
Gotcha: destructive by default
Ask for "clean up X" and you'll get something that deletes. Ask for "read-only first: show me what you'd clean up" and you get a list you can review. I almost always start with the read-only version and only ask for the destructive one once the list looks right.
What doesn't work
- "Fix my server." No context, no evidence, no output shape. You get generic advice.
- Pasting 5,000 lines of logs. Narrow the window. More input isn't more insight.
- Trusting the explanation over the docs. If the model's explanation and
mandisagree,manwins. - Running anything you haven't read. That's the rule. The model is fast, not accountable.
Keep this page open in a tab, steal the templates, adjust the brackets. The structure does most of the work.
