Analyze torch-tensorrt local test results and drive failures to a fix. Use when the user pastes a test report / summary, asks why tests failed, asks to triage or fix failing tests, or mentions the JUnit/test-summary output from `just tests-report` / `just test-summary`. Covers where the JUnit XMLs live, how to read the consolidated report, how to reproduce a single failure, and how to categorize (real bug vs torch-API change vs OOM/skip vs flake).
npx skills add https://github.com/pytorch/TensorRT --skill analyze-test-report
The local test tiers write one JUnit XML per pytest suite, and
tests/py/utils/junit_summary.py aggregates them into one report. The JUnit XMLs are
the source of truth — pytest exit codes can be masked when suites run in
sequence, so always reason from the XMLs / the report, not from "the run exited
non-zero".
JUnit XMLs are written to (first that is set):
$RUNNER_TEST_RESULTS_DIR — set by CI.$TMPDIR/trt_test_results — locally. $TMPDIR defaults to/tmp/torch_tensorrt_$USER, so the usual local path is:
/tmp/torch_tensorrt_<user>/trt_test_results/*.xml
Each file is named after its suite, e.g. l1_dynamo_compile_tests_results.xml,
l0_dynamo_core_runtime_tests_results.xml.
runs every suite past failures, then prints the paste-ready Markdown with node
ids, file, junit path, repro, message, traceback):
just tests-report l1 --agent # l0 | l1 | l2, optionally -ext
just tests-report l2-ext --agent # -ext also installs the model-test deps
Throttle the GPU with just jobs=2 tests-report l2 --agent if it OOMs.
just test-summary --agent # agent Markdown
just test-summary # color-coded terminal report
python3 tests/py/utils/junit_summary.py /tmp/torch_tensorrt_<user>/trt_test_results --agent
If the user pasted a report, work from it directly. If you need more than it
shows (full traceback), open the junit: path it lists.
Each failure block gives you everything to act:
### N. [FAIL|ERROR] classname::name — exact pytest node identity.file: — the test source file.junit: — the JUnit XML; read its <failure> / <error> element for thecomplete traceback (the report caps detail at 40 lines).
repro: — a copy-paste command that re-runs the test.message: / detail: — the headline and (capped) traceback.To pull the full traceback for one failure straight from the XML:
python3 - <<'PY'
import xml.etree.ElementTree as ET
r = ET.parse("<junit-path>").getroot()
for tc in r.iter("testcase"):
for tag in ("failure", "error"):
e = tc.find(tag)
if e is not None:
print(f"== {tc.get('classname')}::{tc.get('name')} ==")
print(e.get("message"), "\n", e.text)
PY
Use the repro line. Notes that matter on this repo:
uv run --no-sync — uses the already-built .venv, does notrebuild torch-tensorrt. (Plain uv run would try to rebuild and fail.)
-n0 forces serial (one process). The default pytest config is -n auto,which spawns a worker per core; on a single GPU that OOMs (CUDA out of
memory + segfaulting workers). For broader local runs use just jobs=2 ....
TMPDIR=/tmp/torch_tensorrt_<user> (or just use the just recipes, whichset it) so the TRT engine/timing cache is writable.
Re-run a single test, then the whole suite once it passes:
TMPDIR=/tmp/torch_tensorrt_$USER uv run --no-sync pytest <file> -k '<name>' -n0
just jobs=2 tests-l1-dynamo-compile # the suite the failure came from
shape/dtype error in py/torch_tensorrt/.... Fix the converter/lowering pass.
RuntimeError/AttributeError from a torch op whosesignature/behavior changed in the nightly (the repo tracks torch nightlies).
Update the call site or the test to the new API; confirm the rule against the
installed torch before editing (uv run --no-sync python -c "...").
CUDA error: out of memory, crashed workers.Not a code bug: too many xdist workers for the GPU, or the GPU is occupied.
Re-run with -n0 / just jobs=2; check nvidia-smi.
test-ext deps(just install-test-ext), and RTX/platform-gated tests skip by design.
Skips are healthy; don't "fix" them.
-n0. Only the narrow cudagraph stream-capture transient is retried in CI (see tests/py/utils/ci_helpers.sh).
junit traceback, open the file, fix.repro (serial). Iterate.just jobs=2 tests-<tier>), thenjust test-summary to confirm the consolidated report is green.
tests/py/utils/ci_helpers.sh(trt_tier_*), shared with CI (.github/workflows/_linux-x86_64-core.yml).
justfile (tests-l0/l1/l2[...], tests-report,test-summary, install-test-ext).
build skill.Statistical visualization. Scatter, box, violin, heatmaps, pair plots, regression, correlation matrices, KDE, faceted plots, for exploratory analysis and publication figures.
Structured guide for setting up A/B tests with mandatory gates for hypothesis, metrics, and execution readiness.
Master dbt (data build tool) for analytics engineering with model organization, testing, documentation, and incremental strategies. Use when building data transformations, creating data models, or implementing analytics engineering best practices.
Master dbt (data build tool) for analytics engineering with model organization, testing, documentation, and incremental strategies. Use when building data transformations, creating data models, or implementing analytics engineering best practices.
Analyze ClickHouse Keeper stress-test results from play.clickhouse.com / keeper_stress_tests data warehouse. Use whenever the user asks about Keeper performance, validates Keeper PRs against stress dashboards, investigates regressions or improvements in Keeper nightlies, asks about specific date windows / SHAs / PR-sets in Keeper stress tests, wants per-PR or window-vs-window comparisons, asks "did this PR break Keeper", asks "what changed in Keeper between dates", or wants a summary report of Keeper stress runs. Triggers on terms like "keeper stress", "keeper PR", "keeper p99", "keeper memory", "keeper rps", "keeper nightly", "keeper-stress-tests", "keeper validation", "keeper regression", or any question referencing the keeper-stress Grafana dashboard. ALWAYS prefer this skill over re-deriving the workflow from scratch — it captures hard-learned lessons about cgroup-vs-Keeper memory, bench-harness confounds, noise floors, and per-PR attribution limits.
Master dbt (data build tool) for analytics engineering with model organization, testing, documentation, and incremental strategies. Use when building data transformations, creating data models, or implementing analytics engineering best practices.
Guide for writing tests for the Aspire Dashboard. Use this when asked to create, modify, or debug dashboard unit tests or Blazor component tests.
Render data visualizations with Canvas2D. Use when the visualization needs high mark counts, fast redraws, immediate-mode rendering, custom hit testing, or a hybrid Canvas plus SVG or HTML architecture.
Take pytorch/analyze-test-report from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.