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.
git clone --depth 1 https://github.com/ujjwal502/debugduckWrote 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/rules/ujjwal502/debugduck/debug)<a href="https://agentmods.dev/rules/ujjwal502/debugduck/debug"><img src="https://agentmods.dev/badge/rules/ujjwal502/debugduck/debug/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/rules/ujjwal502/debugduck/debug"><img src="https://agentmods.dev/badge/rules/ujjwal502/debugduck/debug.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.00057 | $0.01186 |
| Opus 5.5 | $0.00023 | $0.00474 |
| Sonnet 5.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 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 — 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.
- 1mo ago 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 1mo ago), licensed MIT. It adds 57 tokens to every session and 1,186 once invoked, about $0.0002 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 cursor rules, from other repositories
analyze-issue
Read a GitLab issue, identify the root cause (not just symptoms), surface real risks, and produce an implementation approach before writing any code.
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.
marker-bug-to-fix
Take one Marker.io bug report and produce a ready-to-review code fix. Use when asked to fix, investigate, reproduce, or find the root cause of a specific Marker.io issue in the current repository. Pulls the issue's screenshot, console errors, network requests and DOM, locates the cause in code, proposes a minimal…
error-handling-and-validation
A code-quality guide for handling errors, invalid inputs, edge cases, preconditions, logging, and user-friendly error messages.
roslyn-mcp-pitfalls
Known pitfalls and regression lessons from production use.
ui-components
USE WHEN: Building UI components, structuring layouts, and applying styles using Tailwind CSS.