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 onpsanddumatch 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.
