> ## Content Index
> Fetch the complete content index at: https://blog.sudowl.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# The Sysadmin Prompt Cheat Sheet — AI Commands That Actually Work
- URL: https://blog.sudowl.com/sysadmin-ai-prompt-cheatsheet/
- Published: 2026-04-01T12:00:00.000Z
- Updated: 2026-10-11T08:47:37.000Z
- Description: Copy-paste prompts for sysadmin work with Claude or any LLM: explain commands, write scripts, triage logs, review configs, convert Bash to PowerShell.
- Author: Lukas
- Tags: Linux, Windows Server, AI

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.

```text
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](/ollama-local-llm-sysadmin/) 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](/ai-log-analysis-claude-pipe/) 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.

```text
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:

```text
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:

```text
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](/how-i-use-claude-powershell-scripts/).

## 3\. Log triage

```text
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

```text
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](/ssh-hardening-ubuntu-checklist/) — the model's opinion is a second pair of eyes, not the standard.

## 5\. Write a systemd unit

```text
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](/systemd-service-unit-file/).

## 6\. Firewall rules

```text
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](/ufw-firewall-rules-ubuntu/) before running.

## 7\. Translate between Bash and PowerShell

```text
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

```text
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](/build-mcp-server-sysadmin-tools/) is for.

## 9\. Write the post-incident notes

```text
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

```text
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:

```bash
man <cmd>            # or: <cmd> --help | grep -- '--flag'

```

```powershell
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 `man` disagree, `man` wins.
- **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.

---

### Related posts

- [How I Use Claude to Write PowerShell Scripts in 30 Seconds](https://blog.diengdoh.com/how-i-use-claude-powershell-scripts/?ref=blog.sudowl.com)
- [Ollama — A Local LLM for Sysadmin Tasks](https://blog.diengdoh.com/ollama-local-llm-sysadmin/?ref=blog.sudowl.com)
- [Piping Logs Through Claude — AI Log Triage That Actually Helps](https://blog.diengdoh.com/ai-log-analysis-claude-pipe/?ref=blog.sudowl.com)