# Loopx Performance Diagnosis

Diagnose demonstrated CPU, command latency, allocation or IO regressions in an owned...

- Repository: https://github.com/loopx-project/loopx (6526 stars)
- Category: Marketing
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add loopx-project/loopx --skill loopx-performance-diagnosis -g -a claude-code -y`
Codex: `npx skills add loopx-project/loopx --skill loopx-performance-diagnosis -g -a codex -y`
Cursor: `npx skills add loopx-project/loopx --skill loopx-performance-diagnosis -g -a cursor -y`
Gemini CLI: `npx skills add loopx-project/loopx --skill loopx-performance-diagnosis -g -a gemini-cli -y`

## Description

Diagnose demonstrated CPU, command latency, allocation or IO regressions in an owned process with controlled measurements and language-appropriate profilers. Route benchmark effectiveness, score growth and trajectory efficiency to loopx-benchmark; profiling does not qualify a budget or grant execution authority.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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](../loopx-benchmark/SKILL.md). 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.

The rest: https://github.com/loopx-project/loopx/blob/HEAD/skills/loopx-performance-diagnosis/SKILL.md