Agent skill · marketing growth · sickn33
brendangregg-use-tsa
Methodical performance troubleshooting and root-cause analysis with Brendan Gregg's USE and TSA methods, plus evidence-backed RCA and postmortem reports.
Why this skill is useful
Provides a structured methodology for performance troubleshooting and root-cause analysis that includes specific commands and reporting templates not commonly known.
What it needs
Requires linux installed locally. About 6k tokens when loaded. Last updated 2026-08-07. 44,571 stars on the source repository.
What this skill does
Brendan Gregg USE+TSA Performance Analysis Overview A fixed, evidence-first procedure for system performance debugging, root-cause analysis (RCA), and incident reporting, distilled from Brendan Gregg's published methodologies. Instead of running whichever commands happen to be familiar, the agent poses questions first and then finds metrics to answer them: the USE Method (Utilization, Saturation, Errors) sweeps every resource, the TSA Method (Thread State Analysis) decomposes thread time, and off-CPU analysis plus flame graphs drill into what the sweeps find. Every investigation ends in a structured triage note, RCA report, or postmortem where each claim traces to a command and its output. This skill adapts material from the community repository thecsdoctor/brendangregg-use-tsa-skill (full checklists, reference library, and report templates live there). When to Use This Skill Use when a server, VM, or container is "slow" and the cause is unknown Use when latency or throughput regressed after a deploy, config change, or load shift Use when CPU, memory, disk, or network metrics look abnormal and need interpretation Use when an application hangs or threads pile up Use when the user asks for debugging, triage, or root-cause analysis of a performance issue Use when an incident needs an RCA report or a blameless postmortem with an evidence trail How It Works Step 0: Problem Statement Define the problem before measuring. Ask: What makes you think there is a problem? Has it ever performed well? What changed recently (software, hardware, load)? Can it be expressed as latency or run time — quantify it. Who else is affected? What is the environment (OS, versions, config, container/VM limits)? Step 1: 60-Second Triage (Linux) Run the ten-command sweep, checking errors and saturation first (easiest to interpret), then utilization. Record every exonerated resource. Step 2: USE Sweep (resource-oriented) For every resource, check Utilization, Saturation, and Errors. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills sickn33/brendangregg-use-tsa--a9fd16