Claude/ChatGPT Prompt to Generate Production Bash One-Liners for SREs

What this prompt does

This prompt casts the model as a senior SRE and asks for 15 tested, copy-ready bash one-liners for daily operations — not pseudocode. You set [os_target], [shell], [log_path], and [process_name], and it returns one-liners for top memory and CPU processes, tailing and grepping logs with context, curl timing breakdowns, disk usage by directory, safe pattern-based kills, in-place sed with backups, and parallel runs via xargs, each explained in exactly one line.

The structure works because incident work is half about recalling the right one-liner under pressure, so a vetted, parameterised set saves real minutes mid-outage. [log_path] is substituted into the tail-and-grep commands, [process_name] into the inspect-and-kill ones, [shell] ensures the syntax runs in your actual shell, and [os_target] keeps tool flags correct across distributions, since ps, du, and free options drift between distros. Crucially, it flags any destructive one-liner so you know which ones bite. Capping the request at exactly 15 and asking for a one-line explanation each keeps the result scannable — a reference you can paste from quickly, rather than a wall of prose you have to read end to end while a server is down.

When to use it

• You want a vetted set of operational one-liners ready before the next incident.
• You need to tail and grep a specific log path for errors with context lines.
• You're profiling a server and want top memory/CPU and disk-usage commands handy.
• You want a curl timing breakdown (DNS, connect, TTFB, total) for a URL.
• You need to safely kill processes by pattern without a foot-gun.
• You want in-place sed edits with backups and parallel execution via xargs.

Example output

Expect a numbered list of 15 one-liners, each followed by a single-line explanation, covering the six required categories plus common gaps like log rotation, open ports, and file descriptors. The destructive commands — pattern kills and in-place sed — are explicitly flagged so you treat them with care. Each one-liner is shaped to paste and run on a standard Linux box.

Pro tips

• Set [log_path] to your real log so the tail-and-grep one-liners work without editing.
• Put your actual [process_name] in so the inspect and kill commands target the right process pattern.
• Match [shell] to what you actually run; some constructs behave differently outside bash.
• Test the destructive ones — kill and sed -i — on a throwaway box first, exactly as the flagged warnings suggest.
• Keep [os_target] accurate so flags like those on ps and du match your distribution.
• Skim every one-liner before trusting it; a copy-ready command is still your responsibility to verify.
• Save the vetted set somewhere you can reach during an incident, not in a doc you'll have to search for while the pager is going off.
• Use the curl timing one-liner to separate DNS and connect latency from TTFB; that breakdown often points straight at the layer that's slow.