Debugging
Use when something is failing, regressing, or behaving unexpectedly and the goal is root-cause analysis, narrowest fix, and verification. Covers CI/CD, tests, runtime, deployment, and tooling failures. Output should be RCA + fix + prevention, not design options. When in doubt, use this skill.From its SKILL.md
npx -y skills add aayushostwal/nexus --skill debuggingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 17 stars17 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.5 KB, as published. Nobody here has run it
Nexus Debugging
Route to the correct sub-guide and follow it end-to-end.
Compatibility
- Sub-guides:
skills/debugging/ci-cd.md,skills/debugging/codebase.md,skills/debugging/frameworks.md - Shared rules and output formats:
skills/debugging/common.md
Workflow
Step 1 — Classify the Failure
Pick exactly one track:
| Track | Failure origin | Sub-guide |
|---|---|---|
| CI/CD | GitHub Actions, Jenkins, CircleCI, or deployment pipeline log | ci-cd.md |
| Codebase | Failing test, runtime exception, or regression in application code | codebase.md |
| Framework | Django, FastAPI, Bazel, or other tooling misbehavior | frameworks.md |
If unsure: ask "Is the failure in pipeline logs, app code, or a framework?"
Step 2 — Gather Error Context
Before reading the sub-guide, collect:
- Full error message or stack trace — copy exact text, do not paraphrase
- What changed recently: last commit, dependency update, config change, environment change
- Environment details: local vs CI, OS, Python/Node/runtime version
- Steps to reproduce (minimum reproducible case if possible)
Step 3 — Read Sub-Guide & Execute
Read the appropriate sub-guide. Follow its steps in order. Do not skip steps.
Read common.md for shared output format and checklists.
Step 4 — Search for Tool-Specific Errors
If the error is framework-specific or tool-specific:
- Search:
"<exact error message>" <tool-name> <version>— use exact error text - Check the official tool changelog for breaking changes in the version in use
- Check GitHub Issues for the tool repo filtered by the error keyword
Step 5 — Apply Fix & Verify
- Apply the narrowest fix that addresses the root cause — do not clean up unrelated code
- Run the exact verification command that confirms the fix (re-run the failing test or job)
- State what would prevent this from recurring
Output Format
## Debug Report
**Track:** [CI/CD | Codebase | Framework]
**Root Cause:** [one sentence — specific, not "something went wrong"]
**Fix:** [exact command or minimal code diff]
**Verification:** [command to run to confirm fix]
**Prevention:** [what change stops this from recurring]
Anti-Patterns
- Never guess the root cause without reading the full error message and stack trace first.
- Never apply a fix without stating and running a verification step.
- Never mix tracks — pick one sub-guide and follow it completely before considering another.
- Never paraphrase an error message when searching — copy it verbatim.
- Never mark the issue resolved before running the verification command.
- Never clean up unrelated code as part of a bug fix — scope the change to the root cause only.
Examples
Input: User pastes GitHub Actions log:
ModuleNotFoundError: No module named 'pydantic'
Error: Process completed with exit code 1.
Step 1: Track = CI/CD (failure in pipeline)
Step 2: Error = ModuleNotFoundError: No module named 'pydantic'; changed = recent dependency PR; env = GitHub Actions Ubuntu 22.04
Step 4: Search "ModuleNotFoundError: No module named 'pydantic'" github actions → find pydantic missing from requirements.txt
Output:
## Debug Report
Track: CI/CD
Root Cause: pydantic installed locally but not in requirements.txt — CI builds from scratch so it's absent
Fix: pip freeze | grep pydantic >> requirements.txt && git add requirements.txt && git commit -m "fix: add pydantic to requirements"
Verification: Re-run the failing GitHub Actions job — confirm it passes
Prevention: Add a CI step that runs `pip check` after install to catch missing transitive deps
Debugging Specialization
- For CI/CD failures: always check if the failure is environment-specific — works locally but fails in CI = env delta (missing secret, different OS, version mismatch).
- For codebase bugs: always check if a recent commit introduced the regression; use
git bisectif the commit is not obvious. - For framework issues: always check the framework changelog for the exact version in use before assuming it's your code.
- For flaky tests: run the test 5 times in isolation before investigating — confirm it's truly flaky vs. consistently failing.