Roslynk

Combine tools, don't chain calls

When you need several facts before making a change, send them as one multi_query call instead of sequential calls: every operation runs against a single snapshot, so the facts can never disagree with each other. multi_query accepts only the read-only query tools, and each operation uses exactly that tool's own parameter names — a wrong key is error=Invalid naming the key, never silently ignored. Over 25 operations or the output budget, remaining slots return error=Truncated with truncatedSlots=<n>: re-send exactly those operations, passing the response's snapshot= value as expectSnapshot, so a continuation that would straddle a solution change is refused with error=Stale instead of mixing states. The envelope format is in the multi_query section of references/tools.md.

Impact analysis — before renaming a symbol or changing a signature, and whenever someone asks "what uses X", "who calls X", "what breaks if I change X": batch get_symbol + find_references + get_callers + get_callees + find_implementations + get_type_hierarchy in one call, pointing each at the member or type you're changing (get_callers takes methodName, get_callees takes memberName, get_type_hierarchy takes typeName, the others symbolName). get_callers and get_callees are inverses — who calls this member, what does this member call — so alternating them walks a call chain one hop per query. Then follow each reference with get_symbol_body to read the calling convention before editing. Answer with Roslynk, never with grep over *.cs/*.cshtml/*.razor — text search both misses real usages and wrongly matches identically-named symbols.

Understand before editing — when an edit depends on what an expression is (the type behind var, which overload a call picks, whether a value can be null at that point, whether a conversion is implicit or user-defined), call get_expression_info on its position instead of inferring from text; on a declared name (e.g. the x of var x = ...) it reports the declared symbol and its type, like an editor hover. It distinguishes the expression's type from the symbol it binds to — both can matter — and reports a missing fact as none rather than guessing; symbol=none with candidateReason/candidates means the call does not resolve. Batch several positions in one multi_query.

Results are snapshots of a solution that is edited live: re-query after any write rather than reusing an earlier response.

Preview broad edits before writing

Every write tool takes checkOnly=true, which returns the changed-file list without writing anything. Use it whenever a change might be broad — a rename of a widely-used symbol, a whole-solution cleanup — and confirm the scope before applying. Write tools are atomic and stale-guarded: if a target file changed on disk since Roslynk read it, the whole operation is rejected with error=Stale and nothing is written — recompute from current state and retry. Writes go straight to disk and advance the in-memory model immediately, so no reload or rebuild is ever needed afterwards.

Rename parameters with Roslyn

To rename a parameter, call rename_parameter with the declaring member's methodId (add the parameter-type list when overloaded; a constructor is Namespace.Type.Type(int)), the current parameterName and newName. It updates named arguments at call sites and <paramref> docs, and renames the same parameter across overrides, interface members and implementations that use the same old name - check renamedMembers and unchangedRelated in the response to see what was and wasn't cascaded. On error=Conflict pick a name not already used inside the member. Prefer it over rename_symbol for parameters, which cannot target a parameter by name.

Extract methods with Roslyn

To pull code into its own method, call extract_method with the selection (1-based; end column exclusive - endLine+1, column 1 takes whole lines) and a methodName; add asLocalFunction=true for a local function. Preview with checkOnly=true to see the signature and call Roslyn chose. It writes nothing when the selection cannot be extracted safely or the result would not compile - read the NotSupported reason and adjust the selection (whole statements from one block, or one complete expression) rather than extracting by hand.

Check diagnostics once a task's edits are done

The core edit cycle: make all the changes the task needs (any write tools) → get_diagnostics once at the end (bare call; the header always reports error/warning/info/hidden counts; each call compiles and analyzes everything the edits affect, so do not run it after every edit) → if counts are non-zero, re-call with includeErrors=true to see the details → fix each entry via apply_code_fix with its id, line and column → if that returns error=Conflict with candidate= lines, the diagnostic has several fixes: pick the one whose title matches your intent and pass its actionId (the text before the first comma) to apply_code_action; do not retry apply_code_fix → repeat until clean. This replaces dotnet build during development. Pass includeAnalyzers=false for a faster compiler-only pass when style rules don't matter yet.

find_dead_code and find_dead_conditionals never delete anything — treat the results as candidates (public or reflection-used API can be a false positive), confirm intent with the user before bulk-removing, and hand each reported loc span to apply_patch.