Skip to content
Agent Orchestration
Skill

/loopx-performance-diagnosis

Diagnose an owned slow command or runtime with language-appropriate profilers, independent baseline measurements and local-private evidence. Use for demonstrated CPU, wall-time, allocation or IO regressions; profiling does not qualify a budget or grant execution authority.

BOOST
From plugin
loopx
6.2k13 skills1 command
Install
$ npx -y skills add loopx-project/loopx --skill loopx-performance-diagnosis --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/loopx-performance-diagnosis

Context preview

The summary Claude sees to decide when to auto-load this skill.

Diagnose an owned slow command or runtime with language-appropriate profilers, independent baseline measurements and local-private evidence. Use for demonstrated CPU, wall-time, allocation or IO regressions; profiling does not qualify a budget or grant execution authority.

SKILL.md

loopx-performance-diagnosis.SKILL.md
name: loopx-performance-diagnosis
description: Diagnose an owned slow command or runtime with language-appropriate profilers, independent baseline measurements and local-private evidence. Use for demonstrated CPU, wall-time, allocation or IO regressions; profiling does not qualify a budget or grant execution authority.

LoopX performance diagnosis

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.

1. Run the uninstrumented target and record ordinary elapsed time. Use repeated controlled samples for comparisons; profiling time is not a baseline or p95. 2. Verify the optional tool version locally. Preserve the selected interpreter; install optional tools in an isolated environment when authorized. Do not silently install them into product dependencies or fall back on permissions. 3. Write the exact target argv to an ignored JSON array. Run `loopx performance-diagnosis plan --tool TOOL --command-json FILE --output-directory FRESH_IGNORED_DIRECTORY --format json`. Read the whole plan. A plan has not executed or verified tool readiness. 4. Execute `profile_argv` through the Host executor as an argv array without shell interpolation. Capture only the owned process; record failures and coverage gaps. Profile a separate Node worker instead of inferring its CPU from Python transport waits. Do not collect locals or automatically profile unrelated children. 5. Require actual successful target exit and nonempty artifact. Read Speedscope or V8 CPU using `loopx performance-diagnosis inspect --profile-json FILE --format json`; Memray/heap use their own reporters. Keep threads independent and self/inclusive time distinct. Never sum inclusive rows to obtain latency. 6. Turn the hotspot into a falsifiable hypothesis. Use a controlled intervention to distinguish caller/transport, shared semantics and backend cost. Reuse the owning contract; do not skip freshness, authority checks or decision inputs. 7. Repeat the original uninstrumented workload and semantic checks after a fix. Preserve passed, failed and untested results and update the existing checkpoint. Readback of a stack does not prove root cause, improvement or provider admission.

Do not add a new receipt/approval requirement or automatically mutate scheduling, Goal state or telemetry. Stop invoking the workflow to disable it; remove optional tools/captures from their owned local environment when no longer needed.

Read more
Ships withloopx

A control plane with a durable state kernel for long-horizon agents and teams. Keep work moving and improving across sessions, with less human attention.

Get the whole plugin
Stats
6,202
Stars
596
Forks
Active
Maintenance
Python
Language
Apache-2.0
License
10m ago
Last commit
4mo ago
Created
23h ago
Added

Repo: loopx-project/loopx

Other skills on loopx.