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 agentmods add rules/ujjwal502/debugduck/debuggit clone --depth 1 https://github.com/ujjwal502/debugduckWhat 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 | $0.00057 | $0.01186 |
| Opus 5 | $0.00028 | $0.00593 |
| Sonnet 5 | $0.00011 | $0.00237 |
| Haiku 4.5 | $0.00006 | $0.00119 |
Grade A, and why
debug 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 yesterday.
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 — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debug — systematic root-cause debugging
Full procedure and stack-specific playbooks live in skills/debug/. Read
skills/debug/SKILL.md first, then load only the reference files relevant to this bug.
Prime directives
- Reproduce before you diagnose. Diagnose before you fix.
- The bug is where the evidence points, not where it would be convenient. Intuition generates hypotheses; it never concludes.
- One variable at a time. Simultaneous changes destroy causality.
- Binary search beats reading — code path, git history, input, config, timeline.
- A root cause explains 100% of the observed evidence. Unexplained details mean you're not done.
- Prove the fix by toggling it: revert → bug returns; reapply → bug gone.
- Never suppress a symptom you don't understand — no empty catch blocks, blind
?., retries, timeout bumps, or# type: ignoreas a "fix". - Label claims
[observed]/[inferred]/[assumed].
The six phases
- Reproduce — deterministic, minimal, fast command. If it only fails in CI/prod, that environment difference is the primary lead. If you truly can't reproduce, say so and switch to evidence-mining; do not fix on spec.
- Observe — read the entire error, stack traces bottom-up to the deepest frame you own. Logs, network, exit codes, DB state. No theorizing before looking.
- Localize — default: trace the whole path in one pass (
skills/debug/references/trace-first.md). Instrument every checkpoint from entry to symptom at once, numberedCP01…CPnn, write down what each should print, run once, and find the first checkpoint where actual ≠ expected; everything upstream is then ruled out. After instrumenting, stop and hand over the run command — do not guess a fix while waiting for the output. Fall back to bisection (midpoint probes,git bisect run <repro>, halving the input, working-vs-broken diff) when you can't re-run, the path is enormous, or logging perturbs the bug. - Explain — write the causal chain root → symptom. Ask "why" until you reach something worth fixing (the null check isn't the cause; why it was null is).
- Fix — at the root, at the right layer, minimal. No opportunistic refactors in a bug fix.
- Prove — original repro passes; toggle test; regression test verified to fail on the old code; broader suite green; grep for the same bug elsewhere; remove all instrumentation.
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.
- yesterday First seen · 88 lines · 57 tokens per session scan A d9e1d17bce4b
debug is a cursor rule published in the GitHub repository ujjwal502/debugduck (4 stars, last pushed 24d ago), licensed MIT. It adds 57 tokens to every session and 1,186 once invoked, about $0.0003 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 cursor rules, from other repositories
ui-components
USE WHEN: Building UI components, structuring layouts, and applying styles using Tailwind CSS.
react-best-practices
USE WHEN: Designing React components, implementing hooks, and managing component lifecycles.
performance
USE WHEN: Optimizing Core Web Vitals, managing assets, and ensuring high Lighthouse/A11y scores.
fix-issue
Implement a fix following the human-thinking loop — understand the root cause, plan the minimal change, implement, verify the problem is actually gone.
write-issue
Turn a rough idea into a well-structured GitLab issue with clear problem statement, root cause, and testable acceptance criteria.
marker-insights
Aggregate Marker.io website feedback into recurring patterns. Use when asked to find the most common issues on a site, which pages get the most feedback, recurring content problems, or the content-vs-bug split across many Marker.io reports, and produce a prioritized brief for a website team or agency. Read-only: it…