gitnexus-refactoring
Skill36 starsChanged 37 days agoApache-2.0View on GitHub
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\"
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 22
Call list_repos {} before the first tool call.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Refactoring with GitNexus
When to Use
- "Rename this function safely"
- "Extract this into a module"
- "Split this service"
- "Move this to a new file"
- Any task involving renaming, extracting, splitting, or restructuring code
Bind the repository first
Refactoring writes to disk. rename with dry_run: false edits files in
whichever repository was resolved, so binding identity here is a safety gate,
not bookkeeping.
Call list_repos {} before the first tool call. With one indexed repository,
use the examples below as written. With more than one, pass repo on every
call: an omitted repo normally errors, but under an MCP policy with a
configured default it resolves to that default silently. If you cannot tell
which repository is meant, stop and ask. Never run rename with
dry_run: false until the preview in the same bound repository has been
reviewed — its returned file_path values show which checkout is about to be
written, so read them as a confirmation of identity.
list_repos is paginated, so page with offset: pagination.nextOffset until
hasMore is false before concluding a repository is absent.
detect_changes takes worktree when you are editing a linked worktree the
MCP server was not launched from; otherwise git diff runs in the wrong
checkout and reports nothing changed, which reads as a verified refactor.
Workflow
0. list_repos {} → Bind repo (and worktree)
1. impact({target: "X", direction: "upstream"}) → Map all dependents
2. query({search_query: "X"}) → Find execution flows involving X
3. context({name: "X"}) → See all incoming/outgoing refs
4. Plan update order: interfaces → implementations → callers → testsIf "Index is stale" → run
node .gitnexus/run.cjs analyzein terminal.
Checklists
Rename Symbol
- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous
- [ ] rename({symbol_name: "oldName", new_name: "newName", dry_run: true}) — preview all edits
- [ ] Confirm the previewed file paths are in the bound repository/worktree
- [ ] Review graph edits (high confidence) and text_search edits (review carefully)
- [ ] If satisfied: rename({..., dry_run: false}) — apply edits
- [ ] detect_changes() — verify only expected files changed
- [ ] Run tests for affected processesExtract Module
- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous
- [ ] context({name: target}) — see all incoming/outgoing refs
- [ ] impact({target, direction: "upstream"}) — find all external callers
- [ ] Define new module interface
- [ ] Extract code, update imports
- [ ] detect_changes() — verify affected scope
- [ ] Run tests for affected processesSplit Function/Service
- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous
- [ ] context({name: target}) — understand all callees
- [ ] Group callees by responsibility
- [ ] impact({target, direction: "upstream"}) — map callers to update
- [ ] Create new functions/services
- [ ] Update callers
- [ ] detect_changes() — verify affected scope
- [ ] Run tests for affected processesTools
rename — automated multi-file rename:
rename({symbol_name: "validateUser", new_name: "authenticateUser", repo: "my-app", dry_run: true})
→ 12 edits across 8 files
→ 10 graph edits (high confidence), 2 text_search edits (review)
→ Changes: [{file_path, edits: [{line, old_text, new_text, confidence}]}]impact — map all dependents first:
impact({target: "validateUser", repo: "my-app", direction: "upstream"})
→ d=1: loginHandler, apiMiddleware, testUtils
→ Affected Processes: LoginFlow, TokenRefreshdetect_changes — verify your changes after refactoring:
detect_changes({scope: "all"})
→ Changed: 8 files, 12 symbols
→ Affected processes: LoginFlow, TokenRefresh
→ Risk: MEDIUMpartial: true (a graph query failed) or truncated: true (the changed-symbol
listing was capped) means the result is short of the truth: a short or empty
list is not proof that only the expected files changed. Re-run it rather than
treat the refactor as verified.
A wrong-worktree zero carries neither flag and is indistinguishable from a clean verification, so confirm the diffed checkout is the one you edited.
cypher — custom reference queries:
MATCH (caller)-[:CodeRelation {type: 'CALLS'}]->(f:Function {name: "validateUser"})
RETURN caller.name, caller.filePath ORDER BY caller.filePathRisk Rules
| Risk Factor | Mitigation |
| Many callers (>5) | Use rename for automated updates |
| Cross-area refs | Use detect_changes after to verify scope |
| String/dynamic refs | query to find them |
| External/public API | Version and deprecate properly |
| Same name in another indexed repo | Bind repo; verify previewed paths before applying |
Example: Rename validateUser to authenticateUser
0. list_repos {}
→ total: 2 (my-app, billing-api) — both define validateUser, so bind explicitly
1. rename({symbol_name: "validateUser", new_name: "authenticateUser", repo: "my-app", dry_run: true})
→ 12 edits: 10 graph (safe), 2 text_search (review)
→ Files: validator.ts, login.ts, middleware.ts, config.json...
2. Review text_search edits (config.json: dynamic reference!)
3. rename({symbol_name: "validateUser", new_name: "authenticateUser", repo: "my-app", dry_run: false})
→ Applied 12 edits across 8 files
4. detect_changes({scope: "all", repo: "my-app"})
→ Affected: LoginFlow, TokenRefresh
→ Risk: MEDIUM — run tests for these flows
Repository: my-app (/abs/path/my-app) Worktree: same Index: currentWith a single indexed repository, step 0 returns total: 1 and the repo
argument drops out of every call above.
Other versions10 projects use a version of this.
Word for word · 4
- ucsandman/DashClaw★ 310100% same
- kunwarVivek/mcp-github-project-manager★ 104100% same
- pandich93/youtube-niche-finder★ 23100% same
- MarkChu-git/typesafe-mcp★ 2100% same
Edited · 6
- abhigyanpatwari/GitNexus★ 48k42% same
- doobidoo/mcp-memory-service★ 2.1k58% same
- metagit-ai/metagit-cli★ 499% same
- vasceannie/slopgate★ 190% same
- AlexHercules/skills★ 063% same
- ErrorNotFound808/claude-skills★ 083% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository21 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .claude/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- community-growth-analystSkill
- community-repo-issue-pollingSkill
- community-repo-tags-optimizationSkill
- community-store-verify-pluginSkill
- dev-ui-modal-standardSkill
- gitnexus-cliSkill
- gitnexus-debuggingSkill
- gitnexus-exploringSkill
- gitnexus-guideSkill
- gitnexus-impact-analysisSkill
- issue-draft-ticketSkill
- issue-feature-auditSkill
- issue-refine-ticketSkill
- issue-start-ticketSkill
- release-close-sprintSkill
- release-open-sprintSkill
- release-run-pipelineSkill
- test-evaluate-long-runSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

