Loading...
Loading...
Found 37 Skills
Rust debugging skill for systems programming. Use when debugging Rust binaries with GDB or LLDB, enabling Rust pretty-printers, interpreting panics and backtraces, debugging async/await with tokio-console, stepping through no_std code, or using dbg! and tracing macros effectively. Activates on queries about rust-gdb, rust-lldb, RUST_BACKTRACE, Rust panics, debugging async Rust, tokio-console, or pretty-printers.
ABSOLUTE MUST to debug and inspect LLM/AI agent traces using PostHog's MCP tools. Use when the user pastes a trace URL (e.g. /llm-observability/traces/<id>), asks to debug a trace, figure out what went wrong, check if an agent used a tool correctly, verify context/files were surfaced, inspect subagent behavior, investigate LLM decisions, or analyze token usage and costs.
Bootstrap evaluators from production traces — emit SDK code, a framework-agnostic JSON spec, or publish online LLM-judge evaluators directly to Datadog. Use when user says "bootstrap evaluators", "generate evaluators", "create evals from traces", "eval bootstrap", "write evaluators", "build eval suite", "publish evaluators", or wants to generate BaseEvaluator/LLMJudge code or online judge configs from production LLM trace data. Works with ml_app and optional RCA report or failure hypothesis.
Debug errors, test failures, and unexpected behavior with log analysis and correlation. Use when encountering issues, error messages, analyzing logs, or investigating production errors.
Structured workflows for investigating production issues in Honeycomb — the sequence of tool calls (context priming, broad query, BubbleUp, trace analysis, verification) and how to chain results between steps to reach root causes. Trigger phrases: "investigate production issue", "debug latency spike", "find root cause", "use BubbleUp", "analyze traces", "debug an outage", "why is my API slow", "errors are increasing", "health check", "SLO burning", or any request to investigate or debug production problems.
Remap the function_id:pc_index to the original source code position by provided debug info json file.
Help the user systematically identify and categorize failure modes in an LLM pipeline by reading traces. Use when starting a new eval project, after significant pipeline changes (new features, model switches, prompt rewrites), when production metrics drop, or after incidents.
Analyze VictoriaMetrics query trace JSON to diagnose slow queries and produce a structured performance report with time breakdown, bottleneck analysis, and optimization recommendations. ALWAYS use this skill when: (1) the user mentions a VictoriaMetrics or VM trace, query trace, or trace JSON, (2) the user provides or references a JSON file containing duration_msec/message/children fields, (3) the user asks why a VictoriaMetrics/VM query is slow and has trace output, (4) the user asks about vmstorage node distribution, cache misses, or rollup performance in the context of a trace, (5) the user mentions vmselect trace, trace=1, or query performance debugging with VictoriaMetrics. This skill provides a structured report template that ensures consistent, thorough analysis — do not attempt to analyze VM traces without it.
Write raw ClickHouse SQL for a SigNoz dashboard panel — timeseries, value, or table widgets that the builder UI cannot express (custom joins, window functions, regex extraction over log bodies, aggregations beyond builder syntax). Trigger when the user explicitly asks for a "ClickHouse query", a "raw SQL panel", a "custom SQL widget", or describes a SigNoz dashboard panel whose query needs SQL the builder cannot produce. Anchored to dashboard-panel SQL specifically. For ad-hoc data exploration that does not need to land in a panel, use `signoz-generating-queries` instead.
Generate, write, or run an ad-hoc query against SigNoz observability data — metrics, logs, traces, or exceptions — without wrapping it in a dashboard panel or alert. Make sure to use this skill whenever the user asks "show me error rates", "query logs for timeout errors", "what's the p99 latency for the cart service", "how many requests hit the payment endpoint", "find slow traces", "errors in the last hour", or otherwise asks an exploratory question that needs live observability data — even if they don't say "query" or "search" explicitly.
Deep-dive diagnosis of how your AI agent behaves in production. Explores LangWatch analytics and traces end to end to map failure patterns, dissatisfied users, token cost hotspots, edge cases, behavior changes, and outliers, then delivers an HTML report where every finding links to real example traces. Use when you want to truly understand what your agent is doing in production.
Use when the user is investigating QML / Qt Quick performance — both vague complaints ("the UI feels laggy", "this is slow", "frames are dropping", "the app stutters") and explicit asks to profile, find hotspots, or optimize bindings, signals, or rendering. Runs qmlprofiler on a 2D QML application, parses the .qtd trace, and analyzes hotspots against the source with frame-time, memory, and pixmap-cache summaries. Does NOT cover Qt Quick 3D.