The four heights
The same task, four distances: today's deadline, the next reviewer, the stuck moment, the pattern.
Execute — do the immediate task
+Terminate PID 23741 on web-front-03 in a controlled way: send SIGTERM first, wait 15 seconds, then…
Execute — do the immediate task
+Terminate PID 23741 on web-front-03 in a controlled way: send SIGTERM first, wait 15 seconds, then SIGKILL if it still exists. Log who requested the kill, the time, and the process command line. Do not touch any PID owned by root or by user svc-api unless I confirm. Confirm completion back to me.
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
Improve — make it easier to accept
+Before I force-kill a runaway worker, prepare an approval-friendly summary: show its PID, user,…
Improve — make it easier to accept
+Before I force-kill a runaway worker, prepare an approval-friendly summary: show its PID, user, start time, open network sockets, current signal handlers, and whether it holds any open files under /var/lib/app or /data. Flag any process that is part of a supervisor (systemd, supervisord) and recommend the least disruptive signal sequence to stop it.
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
Decide — diagnose the stuck moment
+A background job on queue-host-2 (PID 30210, user queue) has been unresponsive to SIGTERM and is…
Decide — diagnose the stuck moment
+A background worker is stuck and won't respond to SIGTERM.
A background job on queue-host-2 (PID 30210, user queue) has been unresponsive to SIGTERM and is blocking the queue. I can't tell if it's writing to disk or holding DB locks. I'm afraid killing it will leave partial job state or corrupt the DB. What checks can I run now to decide whether to SIGKILL and what cleanup steps to plan if I do?
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
Become — change the pattern
+Our team frequently SIGKILL processes to recover responsiveness, then spend hours restoring state…
Become — change the pattern
+We repeatedly resort to SIGKILL without root-cause.
Our team frequently SIGKILL processes to recover responsiveness, then spend hours restoring state and chasing bugs. This pattern erodes developer confidence and increases outages. What process and cultural change will reduce emergency kills, ensure safer shutdowns, and make developers own graceful termination behavior? Give an implementable checklist for the next 30 days.
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
Next to this one
Other operating system work people do in Linux.
Every task here came from the work, not from a feature list — which is why the prompts name what you want done and never the button that does it. The tool changes; the work does not.
Copyright © LLOS.ai · 2026 — original pedagogy, voice, and design — all rights reserved.
The rest of the map
Same library, five ways in.