Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add ArdurAI/ardur-agent --skill investigate-performance-regressiongit clone --depth 1 https://github.com/ArdurAI/ardur-agentWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/ardurai/ardur-agent/investigate-performance-regression)<a href="https://agentmods.dev/skills/ardurai/ardur-agent/investigate-performance-regression"><img src="https://agentmods.dev/badge/skills/ardurai/ardur-agent/investigate-performance-regression/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/ardurai/ardur-agent/investigate-performance-regression"><img src="https://agentmods.dev/badge/skills/ardurai/ardur-agent/investigate-performance-regression.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00019 | $0.01167 |
| Opus 5 | $0.00010 | $0.00583 |
| Sonnet 5 | $0.00004 | $0.00233 |
| Haiku 4.5 | $0.00002 | $0.00117 |
Grade A, and why
investigate-performance-regression scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 109 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Investigating a performance regression
Performance work goes wrong when it is driven by intuition about what is slow. Your intuition is frequently wrong about where time actually goes. The whole method here is to replace guessing with measurement at every step: reproduce, measure, compare, find the hot path, change one thing, measure again.
The cardinal rule: measure before and after every change. A "fix" you did not measure is a guess you got attached to.
1. Reproduce it reliably
You cannot fix what you cannot trigger on demand.
- Pin down the conditions: which operation, what input size, how much load, warm or cold cache, which environment.
- Build a repeatable harness — a benchmark, a load test, or a script — that produces the slow behavior consistently. Run it several times; if the number swings wildly, stabilize the harness before trusting any measurement.
- Quantify the regression in one sentence: "p95 of
/searchwent from 120ms to 900ms after the 4.2 deploy." A vague "it feels slow" cannot be confirmed fixed.
2. Establish the baseline
Find a known-good point to compare against.
- A previous release, a previous commit, a different environment, or a competitor operation that is fast.
- Measure the baseline with the same harness you will use for the regressed case. Comparing two numbers gathered different ways measures your methodology, not the system.
- If the regression appeared between two known points,
git bisectwith the benchmark as the predicate finds the introducing commit directly. This is often the fastest route to the cause and skips the rest of this process.
3. Profile — find where the time goes
Do not read code looking for slow lines. Profile and let the data point.
- Use a profiler appropriate to the symptom: a CPU profiler for compute-bound slowness, an allocation profiler for GC/memory pressure, a tracer or query log for I/O- and network-bound slowness.
- Distinguish the bottleneck class first: is the time in CPU, in waiting on I/O, in lock contention, or in GC? The fix for each is completely different, and the profiler tells you which without guessing.
- Find the hot path — the small fraction of code where the large fraction of time goes. Profiles are almost always lopsided; one or two frames usually dominate.
- See
@./symptoms.mdfor mapping common symptoms to the likely cause and the tool that confirms it.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 109 lines · 19 tokens per session scan A 33bf7e43cc8e
investigate-performance-regression is a skill published in the GitHub repository ArdurAI/ardur-agent (2 stars, last pushed yesterday), licensed Apache-2.0. It adds 19 tokens to every session and 1,167 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
diagnosing-bugs
Disciplined diagnosis for hard, intermittent, or performance bugs. Use when the user explicitly asks to diagnose, debug, find root cause, or investigate a regression, or when an earlier fix failed. Do not trigger for ordinary feature work or a simple compile error; a diagnosis-only request does not authorize…
python-code-quality
Code quality checks, linting, formatting, and type checking commands for the Agent Framework Python codebase. Use this when running checks, fixing lint errors, or troubleshooting CI failures.
backtest-diagnose
Diagnose failed or underperforming backtests, locate the root cause, and fix the issue.
trace
Use when encountering bugs, test failures, runtime errors, broken builds, or "this doesn't work" reports. Systematic root-cause analysis before any patch — never blind-patches symptoms. Standalone, ends with a final-integration review of the fix. Trigger with /hyperflow:trace, "debug this", "find the root cause", "why…
oma-observability
Intent-based observability + traceability router across layers, boundaries, and signals. Routes to vendor-specific skills via category taxonomy; owns transport tuning, meta-observability, incident forensics. Use for observability, traceability, telemetry, APM, RUM, metrics, logs, traces, profiles, SLO, incident…
oma-debug
Bug diagnosis and fixing specialist - analyzes errors, identifies root causes, provides fixes, and writes regression tests. Use for bug, debug, error, crash, traceback, exception, and regression work.