← ClaudeAtlas

bearing-debugginglisted

Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: "Why is X failing?", "Where does this error come from?", "Trace this bug"
ReidenXerx/bearing · ★ 6 · Code & Development · score 75
Install: claude install-skill ReidenXerx/bearing
# Debugging with GitNexus <!-- BEGIN GENERATED: graph-uncertainty — bearing regenerates this block; edits here are replaced on update --> ## The graph can be wrong A zero is not absence; a near-0.5 `r.confidence` edge is a lead, not proof (~92% of `USES`); a count can be a floor — `impact` says which in `epistemic`. Before a conclusion that matters, confirm with a scoped `Grep` (allowed here, not a gate violation) and say which check you ran. <!-- END GENERATED: graph-uncertainty --> Debugging is the case where this bites hardest: "nothing else calls this" is the premise a wrong root cause is built on. ## Workflow ``` 1. query({search_query: "<error or symptom>"}) → related execution flows 2. context({name: "<suspect>"}) → callers / callees / processes 3. READ gitnexus://repo/{repo}/process/{name} → the flow, in step order 4. trace({from, to}) → shortest A→B path, in one call 5. pdg_query({mode: "controls"|"flows"}) → guards / data flow (needs PDG) ``` > Stale index → `npm run bearing:agent-refresh` (always includes `--embeddings`; an index > without them counts as stale). ## Symptom → approach | Symptom | Approach | | --- | --- | | Error message | `query` the error text → `context` on throw sites | | Wrong return value | `context` on the function → `pdg_query flows` for the data | | Intermittent failure | `context` → look for external calls and async deps | | Recent regression | `detect_changes` — w