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 hani-q/qstack --skill qstack-fix-root-causesgit clone --depth 1 https://github.com/hani-q/qstackWrote 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/hani-q/qstack/qstack-fix-root-causes)<a href="https://agentmods.dev/skills/hani-q/qstack/qstack-fix-root-causes"><img src="https://agentmods.dev/badge/skills/hani-q/qstack/qstack-fix-root-causes/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/hani-q/qstack/qstack-fix-root-causes"><img src="https://agentmods.dev/badge/skills/hani-q/qstack/qstack-fix-root-causes.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.00079 | $0.00829 |
| Opus 5.5 | $0.00032 | $0.00332 |
| Sonnet 5.5 | $0.00016 | $0.00166 |
| Haiku 4.5 | $0.00008 | $0.00083 |
Grade A, and why
qstack-fix-root-causes 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 1mo 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 — 68 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Fix root causes
Diagnosis precedes remediation. A request to diagnose is read-only and does not authorize implementing a fix, adding instrumentation, clearing state, or changing every related instance. It also does not authorize commits, pushes, publishing, deployment, or external messages.
Diagnose a failure
- Reproduce the symptom with the smallest faithful path. If it cannot be reproduced, state that limitation and keep the eventual fix unverified.
- Gather the actual error, state, inputs, and timing. Use existing logs and observability first; instrument only when the request authorizes that edit.
- Follow the causal chain by repeatedly asking why each observed condition exists. Stop at the layer whose behavior explains the full reproduction.
- Reject symptom patches such as a nil guard that merely silences a crash or a long comment defending a workaround.
- Search for the same causal pattern across the relevant codebase. Report out-of-scope instances, but modify only the authorized scope.
- For failures that appear only after restart, inspect changing persistent state before unchanged code: configuration, caches, lockfiles, serialized state, and abandoned temporary artifacts. Clearing state can support a diagnosis; it is not itself a durable fix.
Report the reproduction, evidence, causal chain, root cause, pattern scan, proposed repair, and verification path. Implement only when the user's request includes fixing the problem.
Trace a constraint
A cost, an estimate, a limit, or "we always do it this way" is a claim with a source, not a fact to plan around. Follow its causal chain the same way.
- Quote the constraint as stated and name its source: a person, a ticket, a vendor quote, a past plan, or a measurement. "The ticket says so" locates the source; it is not the evidence.
- Break the constraint into the parts that produce it. Stop one or two levels below the claim, where the verdict stops changing.
- Tag each part. Fixed: physics, math, or a measured limit, with the evidence cited. Priced: a contract, regulation, or policy that can change, with its change cost named. Inherited: a habit, an old estimate, or an analogy to a past project, with nothing behind it.
- Compute the floor from the fixed parts alone, using the few parts that dominate it. Say what the gap between the floor and the claim is made of and whether it is removable.
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.
- 1mo ago Changed · +26 lines · +32 tokens per session 249659043651
- 1mo ago First seen · 42 lines · 47 tokens per session scan A 7e3435419dae
qstack-fix-root-causes is a skill published in the GitHub repository hani-q/qstack (7 stars, last pushed 3d ago), licensed MIT. It adds 79 tokens to every session and 829 once invoked, about $0.0003 per session on Opus 5.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
debug-optimize-lcp
Guides debugging and optimizing Largest Contentful Paint (LCP) using Chrome DevTools MCP tools. Use this skill whenever the user asks about LCP performance, slow page loads, Core Web Vitals optimization, or wants to understand why their page's main content takes too long to appear. Also use when the user mentions…
systematic-debugging
Use when debugging a failing test, build error, or runtime issue that isn't immediately obvious. Guides a 4-phase root cause analysis instead of random fix attempts.
log-error-digest
Analyze log files to troubleshoot errors, identify peak error periods, and produce error clustering, frequency statistics, and time distribution reports. Supports JSON, syslog, and Nginx formats with automatic detection. Use when a user uploads a .log file and asks to analyze errors, find patterns, debug issues, or…
cwv-optimizer
Diagnose and fix Core Web Vitals issues on AEM Edge Delivery Services pages. Goes deeper than generic CWV advice by understanding EDS-specific performance patterns including the 100KB LCP budget, E-L-D loading phases, block rendering behavior, and third-party script impact. Produces specific fixes for LCP, CLS, and…
incident-response-incident-response
Coordinate production incident triage, mitigation, investigation, recovery, and follow-up. Use when responding to outages or other incidents that require structured operational coordination.
ci-fixer
CI failures - read error, minimal fix, verify.