The four heights
The same task, four distances: today's deadline, the next reviewer, the stuck moment, the pattern.
Execute — do the immediate task
+We need better responsiveness on the production fleet before Monday. Audit the three busiest…
Execute — do the immediate task
+We need better responsiveness on the production fleet before Monday. Audit the three busiest servers, identify CPU, memory, I/O, and lock contention hotspots over the last 24 hours, apply the agreed tuning changes to sysctl and process limits, and reboot only if safe. Produce before/after metrics for 1‑minute load, 95th‑percentile latency, and swap usage.
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 submit this tuning plan to ops leadership, make the case they’ll approve. Put the expected…
Improve — make it easier to accept
+Before I submit this tuning plan to ops leadership, make the case they’ll approve. Put the expected user‑visible improvement up top, list the exact kernel parameters and rationale, show the rollback plan, and flag any risk to running jobs or scheduled backups so they can sign off quickly.
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
+I bumped vm.swappiness and increased file descriptor limits on two app nodes and load spiked the…
Decide — diagnose the stuck moment
+Load spikes after a config tweak
I bumped vm.swappiness and increased file descriptor limits on two app nodes and load spiked the next hour. I’m worried I misread the workload profile or caused more cache churn, and the DBA is watching disk I/O. What is the most likely explanation and what immediate measurements and rollbacks should I run to restore stability?
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
Become — change the pattern
+Every quarter we reapply ad‑hoc kernel tweaks and later discover a different service regresses,…
Become — change the pattern
+Performance tuning repeats same regressions
Every quarter we reapply ad‑hoc kernel tweaks and later discover a different service regresses, costing hours and a support escalation. I want fewer surprises. Where are we losing credibility and what one repeatable habit — in testing, change control, or monitoring — would prevent this pattern?
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.