Refactoring C# Symbols

This skill ships a Roslyn-based C# rename CLI in src/. It is intentionally one-shot and stateless: one call resolves the target, validates the request, and returns either a preview or an applied rename. There is no public prepare step.

Contents

• Canonical CLI
• Contract
• How To Use It
• Monorepo Directory Mode
• Important Behavioral Rules
• Supported Targets
• File Rename Nuance
• Error Handling
• Success Criteria
• Recommended Output Style

Canonical CLI

If the skill was installed by install.sh, prefer the prebuilt CLI:

bin/csharp-refactor rename-symbol <sln|slnx|directory> <file> <line> <oldName> <newName> [dryRun=false|true]

Otherwise run the bundled source CLI from the skill directory:

dotnet run --project src/CSharpRefactoring.Cli -- rename-symbol <sln|slnx|directory> <file> <line> <oldName> <newName> [dryRun=false|true]

When invoked from outside the skill directory, use an absolute project path:

/<skill-dir>/bin/csharp-refactor rename-symbol <sln|slnx|directory> <file> <line> <oldName> <newName> [dryRun=false|true]
# or, if no prebuilt binary is installed:
dotnet run --project /path/to/refactoring-csharp/src/CSharpRefactoring.Cli -- rename-symbol <sln|slnx|directory> <file> <line> <oldName> <newName> [dryRun=false|true]

The tool project may create normal bin/ and obj/ directories under the skill. That is expected and useful: it lets repeated runs reuse the .NET build cache instead of rebuilding the CLI from scratch.

The target solution is not redirected to a temporary build output. The CLI opens the solution from the solution directory and lets Roslyn/MSBuild use the target project's normal build cache (obj/, bin/, or the repository's configured artifacts layout). This is intentional: it avoids creating a second cache tree for the project being refactored and lets repeated renames benefit from the project's existing MSBuild/Roslyn design-time build cache.

Contract

How To Use It

1. Use rg -n to locate the symbol and copy the 1-based line number directly.
2. Call rename-symbol once without the dryRun argument for normal rename requests. This applies the rename.
3. Use dryRun=true only when the user explicitly asks for preview, when the target is ambiguous, or when the rename is unusually broad/risky and applying immediately would be irresponsible. The CLI also accepts true, --dry-run, dryRun=false, false, and --no-dry-run; invalid values fail fast and must never silently apply.
4. Do not run a dry run just because the tool supports it. The tool loads the solution on every call, so preview+apply doubles the cost on large projects.
5. Summarize the result by reporting the original name, new name, changed document count, total text changes, changed files, and any file move.

Monorepo Directory Mode

Use directory mode only when a repository contains multiple .sln/.slnx files or shared projects that are not all present in one normal solution. For ordinary repositories, pass the specific solution file because it is faster and avoids scanning unrelated projects.

When solution_path is a directory:

• Pass the repository or workspace root as solution_path.
• Keep file_path as the absolute path to the target source file.
• The tool recursively discovers .sln, .slnx, and supported project files under the directory.
• It merges them into one temporary .slnx, opens that aggregate solution, performs the rename, and deletes the temporary solution directory before returning.
• The temporary aggregate solution lives outside the target repository; source files and normal project build caches remain in their original locations.

Important Behavioral Rules

• The tool is stateless. It loads the solution on every call.
• If solution_path is a directory, the tool scans it recursively, merges discovered .sln, .slnx, and project files into one temporary .slnx, opens that solution, runs the rename, and deletes the temporary solution directory before returning.
• A preview does not reserve state. If the workspace changes between preview and apply, rerun the preview.
• Prefer one apply call over preview+apply when the user already asked to perform the rename.
• For a .sln/.slnx input, the tool runs Roslyn from the target solution directory. For a directory input, it runs Roslyn from that directory while opening the temporary aggregate solution. In both modes, project files stay in place and use the target project's normal MSBuild outputs.
• Do not invent a session or hidden prepare state.
• Do not ask for a column number. The tool resolves from file_path, line_number, and old_name.
• old_name is mandatory because it disambiguates the target when a line contains more than one renameable identifier.
• The bundled source requires .NET 10 and restores NuGet packages on first run.
• Let the tool keep its own normal bin/ and obj/ cache unless the user explicitly asks for a clean/no-cache run.
• If the tool returns a preview, say preview. If it returns applied changes, say applied.
• Keep responses concise and action-oriented. Tell the user what changed and whether a file move happened.

Supported Targets

Treat these as supported rename targets when the Roslyn symbol is source-backed and CanBeReferencedByName:

• NamedType
• Method
• Property
• Field
• Event
• Parameter
• Local
• TypeParameter
• Namespace

Do not rename constructors, destructors, static constructors, or indexers.

File Rename Nuance

rename_file=true is a convenience default, but it only produces a real safe move when the symbol is a single-declaration named type and the file stem matches the current type name.

If the tool does not return file_move_from_path and file_move_to_path, the symbol rename is still valid, but the file itself was not moved. Do not claim a file rename happened unless the tool reports it.

This is intentionally conservative so git sees a tracked rename instead of a delete+add pair.

Error Handling

Use the tool's error codes as actionable guidance:

Success Criteria

A rename workflow is complete when:

• The target was resolved from line_number + old_name.
• The user approved the rename, or explicitly requested a dry run only.
• The tool returned changed documents, total text changes, and any file move details.
• The final answer makes the applied scope clear enough for the user to trust the change.

Recommended Output Style

• For previews, say what would change and that nothing was applied.
• For applied changes, say what changed and whether the file was moved.
• If the file move fields are present, mention them explicitly.
• If the tool returned an error code, echo the code and the human-readable reason.