← ClaudeAtlas

bearing-feature-devlisted

Use when ADDING new code — implement a feature, add an endpoint/handler, wire in a new module. The graph finds existing patterns to reuse and the right place to integrate. Examples: "add a feature that does X", "where do I wire this in", "implement X like the existing Y", "add a new endpoint".
ReidenXerx/bearing · ★ 6 · AI & Automation · score 75
Install: claude install-skill ReidenXerx/bearing
# Feature development 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 --> Refactoring changes existing code; **this is about adding it well** — reuse the codebase's patterns instead of reinventing, and wire into the *right* place. The graph is how you find both. ## Workflow ``` 1. query({search_query: "<similar existing feature>", goal: "pattern to reuse"}) → find prior art 2. READ gitnexus://repo/{name}/clusters → pick the right functional area 3. context({name: "<closest existing example>"}) → copy its shape (deps, signature, error handling) 4. context({name: "<integration point>"}) → where you'll hook in (router, registry, factory) 5. impact({target: "<integration point>", direction: "upstream"}) BEFORE wiring → who else uses it; don't break them 6. implement following the reused pattern 7. detect_changes({scope: "unstaged"}) + impact on the new wiring → confirm scope matches intent ``` > Stale index → `npm run bearin