debugging
Has your agent investigate and fix errors in any type of code or program. Helps find the cause of crashes, slowdowns, or unexpected behaviors.
What it does
This tool helps find and fix bugs in computer programs. It works by investigating the program's actual behavior to discover the cause of the problem, rather than just guessing based on the code.
When to use it
- ✓When a program crashes unexpectedly.
- ✓When a program doesn't work as expected but shows no clear error.
- ✓When a program is slow or unresponsive.
Example of what to ask your AI
“My Python program crashes when I try to save a file, can you help me figure out why?”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
The tool first checks how the program behaves in real-time to understand the issue. Then, it uses specific guides for the language or program type to find the exact solution and ensures the bug doesn't reappear.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add code-yeongyu/oh-my-openagent --skill debuggingOr download just the file:
curl -L https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/dev/packages/shared-skills/skills/debugging/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
Debugging
You are a hypothesis-driven debugger. Two disciplines apply regardless of language, runtime, or whether you have source:
- Runtime truth beats code reading. Every claim about why the bug happens must come from observed state — never from a plausible story spun from reading code.
- Leave no trace. Debugging creates artifacts. Every artifact is journaled and removed before you call the task done.
The rest of this file is a map. The knowledge is in references/. This file cannot teach you how to debug — it can only tell you which reference will, for your exact situation.
🚨 READ THE REFERENCES. THIS IS NOT OPTIONAL.
This skill is intentionally small. Ninety percent of what you need to know lives in
references/. If you skim this file and start working without opening the references, you will reattach a debugger the wrong way, miss a silent-failure pattern you've never seen before, waste an hour on a source-map gotcha, or invent a worse version of a tool that already solves your problem.Every reference below is mandatory when its scenario applies. "I know this language" is not an exemption. The references exist because every runtime and every specialist tool has at least one gotcha that silently wastes hours, and you will not know which gotcha until you read the file.
The gate rule: before you run a command from a given reference's domain, you must have read that reference in this session. Re-reading across sessions is cheap. Guessing is expensive.
Runtime Setup — MANDATORY READING BEFORE ATTACHING
The methodology is language-agnostic. The commands to launch, attach, breakpoint, and inspect are not. Open the matching reference before Phase 0. Not during. Not after.
| Your runtime is… | Open this before attaching anything | Non-negotiable because… |
|---|---|---|
| Python (CPython, pytest, asyncio, Django, FastAPI) | 📖 references/runtimes/python.md | pdb vs ipdb vs debugpy vs pytest --pdb all have different attach semantics. Async code needs special breakpoint handling. Wrappers like poetry run swallow flags. |
| Node.js / tsx / ts-node / Bun / Deno (running source) | 📖 references/runtimes/node.md | tsx + node inspect CLI has a silent source-map failure — breakpoints by line number do not fire. You will not notice unless you read this first. |
| Rust (cargo, tokio, panics) | 📖 references/runtimes/rust.md | Release builds strip symbols. Tokio tasks need tokio-console. The borrow checker makes dbg! the faster tool most of the time. |
| Go (goroutines, dlv, pprof, race) | 📖 references/runtimes/go.md | Goroutine leaks and recovered panics are silent by default. dlv has a specific port convention. go test -race is the first thing to run, not the last. |
| Native binary / stripped C/C++ / no source | 📖 references/runtimes/native-binary.md | The workflow (triage → dynamic → static → scripted repro) is counterintuitive if you've never done it. strings -n 8 silently drops short interpolations like ${x} — read bytes directly for any extraction that matters. macOS adds SIP / Mach-O / lldb specifics that don't apply on Linux. |
| Bundled-app binary (Bun SEA, Node SEA, Deno compile, pkg, nexe, Electron, Tauri, PyInstaller) | 📖 references/runtimes/bundled-js-binary.md | These look like Mach-O / ELF but their high-level source is recoverable with the right per-bundler tool — Ghidra is overkill. Source-format reality varies: Bun/pkg/nexe/Electron-asar are usually plaintext; Node SEA with code-cache, PyInstaller .pyc, and Deno eszip need extra tooling; Tauri's Rust core still needs native-binary.md. Workflow: identify bundler → locate bundle → extract with the bundler-specific tool → grep. |
If you cannot honestly say you just opened the reference for your runtime, open it now.
🚨 Native binary vs bundled binary — check before committing:
file ./targetcalls them both Mach-O / ELF. The 30-second discriminator isdu -h ./target(50 MB+ suspect bundled) plusstrings -n 12 ./target | rg -iE 'bun|node_modules|webpack|esbuild|deno|pkg/lib|electron|pyinstaller|nexe|NODE_SEA_FUSE|tauri'. If hits → bundled-js-binary.md. If clean → native-binary.md.
…
FAQ
Do I need to be a programmer to use this?
You don't need to be an expert, but having a basic idea of what the program should do helps a lot in identifying the problem.
Does it work for any type of program?
Yes, it has guides for various programming languages and program types, including those without visible source code.
What are 'references'?
These are detailed guides that explain how to use specific tools for each type of problem or programming language. It's important to consult them before starting.
Details
Original description by the author
Runs a hypothesis-driven debugging loop across any language or binary, escalating to orthogonal oracle angles and locking the fix with a failing test. Use for crashes, silent failures, hangs, wrong responses, memory leaks, async misbehavior, or reverse engineering.
Popularity
- GitHub stars
- 70k
- Ranking position
- #1737
- License
- NOASSERTION
- Updated
- 10/16/2026
Comments
- …
More skills from this repository
comment-checker
Helps your agent understand and respond to feedback from automatic comment checkers. It's useful when the agent needs to process information from tools that automatically review code or content.
code-yeongyu/oh-my-openagent
lcx-contribute-bug-fix
Helps your agent contribute bug fixes for LazyCodex-related projects. It creates issues or pull requests to ensure code quality.
code-yeongyu/oh-my-openagent
lcx-doctor
Lets your agent check the health of LazyCodex and Codex CLI installations. It's useful when the system behaves oddly after updates or changes.
code-yeongyu/oh-my-openagent
lcx-report-bug
Helps your agent report bugs in detail for LazyCodex projects. It creates issues with useful information for developers to fix the problem.
code-yeongyu/oh-my-openagent
Similar skills
benchmark-optimization-loop
Has your agent improve something's speed in a measured way. It tests multiple versions and chooses the fastest one that still works correctly.
affaan-m/ECC
change-impact
Helps your agent analyze the impact of code changes before making them. It compares the planned vs. actual results afterward, covering paths, data, tests, and documentation. Useful for risky or system-wide changes.
affaan-m/ECC
click-path-audit
Lets your agent trace all user buttons and interactions to find bugs. It finds issues where functions seem to work alone but fail together. Useful when bugs persist even after debugging.
affaan-m/ECC