← ClaudeAtlas

bearing-refactoringlisted

Use when the user wants to rename, extract, split, move, or restructure code safely. Examples: "Rename this function", "Extract this into a module", "Refactor this class", "Move this to a separate file"
ReidenXerx/bearing · ★ 6 · Code & Development · score 75
Install: claude install-skill ReidenXerx/bearing
# Refactoring with GitNexus ## `rename` is not all graph — check the tag on every edit Every edit in a `rename` preview is tagged `confidence: "graph"` (resolved through the knowledge graph) or `confidence: "text_search"` (a regex match — find-and-replace, labelled). **The ratio varies wildly and is not the point.** One measured rename came back 4 graph / 3 text_search; another, 36 / 1. What matters is WHICH edit is regex — in the second, the lone text_search hit was the only production caller, and every confident edit was in the spec file. `dry_run: true` is the default for a reason. Compare `graph_edits` against `text_search_edits`, read every `text_search` line on its own merits, and run `detect_changes` afterwards. "Safer than find-and-replace" is true and does not mean "is not find-and-replace". <!-- 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 --> ## Workflow ``` 1. impact({target: "X", direction: "upstream"}) → Map all dependents 2. query({search_query: "X"}) → Find execution flows involving X 3. context({name: "X"})