From refute
Drive a single symbol-aware rename via `refute rename` with strict preview-then-apply discipline — confirm backend health with `refute doctor`, capture a preview diff for user review, then apply only after explicit approval and report the affected files.
How this skill is triggered — by the user, by Claude, or both
Slash command
/refute:refute-renameThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Recommended model: mid. Procedural refactor driver with judgment on
Recommended model: mid. Procedural refactor driver with judgment on disambiguating symbols and interpreting backend warnings.
Perform exactly one symbol rename in a project, gated by an explicit preview-and-approve step. The skill must never apply an edit the user has not seen.
Supported languages: Go (gopls), Rust (rust-analyzer), TypeScript / JavaScript (typescript-language-server). Out of scope: Java, Kotlin, cross-language renames, multi-step refactors.
path:line) to
disambiguate when the same name appears in multiple scopes.If the new name is missing or identical to the old name, stop and ask.
Before touching code, run:
refute doctor
(or go tool refute doctor if the project pins Refute as a Go-tool
dependency.)
Detect the relevant language from project markers:
go.mod → Go (gopls)Cargo.toml → Rust (rust-analyzer)package.json / tsconfig.json → TypeScriptParse the doctor output for the backend that matches the target file
(or all relevant ones if no file hint was given). The backend must be
reported READY and must list rename among its usable operations.
Refuse to proceed when the relevant backend is:
rename operation as unsupported.In that case, surface the exact remediation command from the doctor
output and stop. Do not run refute rename. Point the user at
refute-doctor for a fuller diagnosis if needed.
With a healthy backend, run:
refute rename --preview <OLD> <NEW> [--file <PATH[:LINE]>]
Capture both stdout (the unified diff) and stderr (backend warnings).
If the CLI uses a different preview flag in this project's pinned
version, infer it from refute rename --help — but never substitute
apply mode for preview.
If the preview command exits non-zero, report the error verbatim and stop. Do not proceed to apply.
Present to the user:
If the diff is empty, report "no matches" and stop — do not apply.
If backend warnings indicate ambiguity, conflicts, or partial coverage (for example: shadowed names, generated files skipped, build errors in the workspace), surface them and ask the user whether to proceed before requesting approval.
Ask the user to approve the diff. Acceptable approvals:
Anything ambiguous, conditional, or asking for changes counts as not approved. Do not apply. If the user asks for a different new name or a narrower scope, restart from step 2 with the updated inputs.
On explicit approval, re-run with apply mode:
refute rename --apply <OLD> <NEW> [--file <PATH[:LINE]>]
If the apply step exits non-zero, report the error verbatim and run
git status so the user can see whether any partial edits landed.
Do not attempt to roll back automatically.
After a successful apply, run:
git status --short
Report:
git status),Renamed <OLD> → <NEW> across N file(s) via <backend>.,npx claudepluginhub shatterproof-ai/agents --plugin refuteCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.