LoopX performance diagnosis

First identify the question. For a LoopX-managed benchmark's outcome quality, score growth, useful progress per time/token, or agent trajectory, use loopx-benchmark. A flatter score curve, repeated reads or more tokens alone do not establish a process-performance regression. Keep that analysis with the benchmark owner; use this skill as a focused subtask only when evidence identifies a slow owned command or resource cost. Do not require a profiler before analyzing effectiveness or interaction overhead.

Read the current Goal/Todo contract and repository optimization evidence rules. State the real user operation, observed failure and owning acceptance. Preserve the exact source, runtime/interpreter, backend/history, inputs and concurrency. Use an owned disposable target for writes. Do not attach to a production process, elevate privileges, weaken OS policy, or start paid/remote workloads without the existing authorization. Raw stacks, paths, arguments and profiles stay ignored and local-private; public summaries contain only generalized evidence.

Read loopx/capabilities/performance_diagnosis/README.md for tool selection and blind spots. On installed copies use loopx capability show performance-diagnosis to locate its canonical documentation. Python waits/startup: Pyinstrument; Python threads/native on Linux: py-spy; allocations: Memray; Node/TS: V8 CPU/heap. Go/JVM/kernel costs need their native tools. Research official sources when the installed runtime or missing evidence makes the documented choice uncertain. Do not choose a tool from popularity or claim one profiler covers every layer.