Skip to main content
skill CX Codex

lsp-edit-export — Claude Code skill: what it does, how to install

A guided workflow for editing exported symbols and public APIs. It finds every caller via LSP, pauses for explicit confirmation, and verifies the build.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add blackwell-systems/agent-lsp --skill lsp-edit-export -a claude-code
Open on GitHub

What lsp-edit-export does

This skill automates safe refactoring for public APIs, exported types, and package-level functions. Before touching any file, it locates the definition using mcp__lsp__go_to_symbol and discovers every call site with mcp__lsp__find_references. The confirmation gate is mandatory. Even if the tool finds zero callers, it displays an impact summary and halts until you explicitly approve the change.

Once approved, the skill edits the declaration and affected callers, captures before-and-after diagnostics, and triggers mcp__lsp__run_build. Replacing full function bodies is handled cleanly by mcp__lsp__replace_symbol_body. Without the agent-lsp MCP server providing referencesProvider, the workflow cannot run.

What it helps with

  • trace external call sites before modifying a function signature
  • rename exported symbols across multiple packages
  • replace entire symbol bodies without manual line offsets
  • catch compiler diagnostics immediately after public API edits

Example prompts for the agent

  • Use lsp-edit-export to update the signature of codec.Encode
  • Rename the exported Buffer struct across the project using lsp-edit-export
  • Refactor method Buffer.Reset with lsp-edit-export

How to install lsp-edit-export

1Skills CLI (Vercel)

npx skills add blackwell-systems/agent-lsp --skill lsp-edit-export -a claude-code

2Manually: put the files in place

~/.claude/skills/lsp-edit-export/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/lsp-edit-export/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about lsp-edit-export

How do I install lsp-edit-export in Claude Code?

Run npx skills add blackwell-systems/agent-lsp --skill lsp-edit-export -a claude-code. You can also place the skill file into ~/.claude/skills/lsp-edit-export/SKILL.md.

What does lsp-edit-export do?

It guides code agents through a safe public API edit sequence by locating callers via LSP, requiring user confirmation, applying edits, and testing the build.

What is required to run lsp-edit-export?

You need the agent-lsp MCP server with referencesProvider capability active in your workspace. Without this server, the LSP lookup and diagnostic tools will fail.

Source text

SKILL.md · MIT
---
name: lsp-edit-export
description: Safe workflow for editing exported symbols or public APIs. Use when changing a function signature, modifying a public type, or altering any symbol used outside its own package — finds all callers first so nothing breaks silently.
argument-hint: "[symbol-name]"
user-invocable: true
allowed-tools: mcp__lsp__go_to_symbol mcp__lsp__open_document mcp__lsp__find_references mcp__lsp__get_diagnostics mcp__lsp__run_build mcp__lsp__replace_symbol_body Edit Write
license: MIT
compatibility: Requires the agent-lsp MCP server (github.com/blackwell-systems/agent-lsp)
metadata:
  required-capabilities: referencesProvider
  optional-capabilities: workspaceSymbolProvider
---

> Requires the agent-lsp MCP server.

# lsp-edit-export

Safe workflow for editing exported symbols. Always discovers all callers before
touching any code, then verifies the change is clean.

## When to Use

Use this skill whenever you intend to change the signature, name, or behavior of
an **exported symbol**: a symbol visible outside its defining package or module.

**Language-specific definitions:**

| Language   | Exported means...                                                      |
|------------|------------------------------------------------------------------------|
| Go         | Identifier starts with an uppercase letter (e.g. `MyFunc`, `MyType`)  |
| TypeScript | Has `export` keyword; or is a public class member (no `private`)       |
| Python     | Not prefixed with `_`; or explicitly listed in `__all__`               |
| Java/C#    | Has `public` or `protected` visibility modifier                        |
| Rust       | Has `pub` keyword                                                      |

If you are unsure whether a symbol is exported, treat it as exported and run
this workflow anyway. The cost is a few extra tool calls; the benefit is never
breaking a hidden caller.

**Do NOT skip this workflow** even when you believe there are zero callers.
The confirmation gate in step 3 exists precisely for that case.

## Workflow

**If LSP is not yet initialized**, call `mcp__lsp__start_lsp` with the
workspace root first. (agent-lsp supports auto-inference from file paths, so
explicit start is only required when switching workspaces or on a cold session.)

### Step 1 — Locate the symbol

Use `go_to_symbol` to find the symbol's definition by name, without needing to
know its file path or line number in advance:

```
mcp__lsp__go_to_symbol({
  "symbol_path": "PackageName.ExportedFunction",
  "workspace_root": "/abs/path/to/repo"   // optional, narrows scope
})
```

`symbol_path` uses dot notation. For a top-level function `Encode` in package
`codec`, use `"codec.Encode"`. For a method `Reset` on type `Buffer`, use
`"Buffer.Reset"`. The last component is the leaf name; any prefix is used to
disambiguate when multiple symbols share the same leaf.

The tool returns a `FormattedLocation` with the definition file and 1-indexed
line/column. Record this position — you will need it in step 2.

### Step 2 — Discover all callers

Call `find_references` using the `position_pattern` field to express the cursor
position as a readable text pattern rather than raw coordinates. The `@@` marker
indicates exactly where the cursor sits (the character immediately after `@@`):

```
mcp__lsp__find_references({
  "file_path": "<definition file from step 1>",
  "position_pattern": "func @@ExportedFunction(",
  "include_declaration": false
})
```

The `@@` must immediately precede the first character of the symbol name.
Examples:

- `"func @@Encode("` — Go function declaration
- `"type @@Buffer struct"` — Go type declaration
- `"export function @@parse("` — TypeScript function
- `"class @@Parser:"` — Python class
- `"pub fn @@process("` — Rust function

If `position_pattern` is unavailable on your MCP client, fall back to the
`line` and `column` fields from the location returned in step 1.

The tool returns a list of reference locations across the codebase.

### Step 3 — Confirmation gate (REQUIRED — never skip)

Before making any change, present the impact summary to the user and ask for
explicit confirmation. This gate is mandatory even when the caller count is zero.

Format the gate as follows:

```
## Impact Check: <SymbolName>

- Definition: <file>:<line>
- Callers found: N reference(s) in M file(s)

Files with callers:
  - <file1>
  - <file2>
  ...

Proceed with the edit? [y/n]
```

If the user answers **n**, stop. Do not make any edits.

If the user answers **y**, proceed to step 4.

**Why this gate exists even for 0 callers:** the LSP index may be incomplete
(e.g. files not yet saved, workspace not fully loaded). Zero callers is a data
point, not a guarantee.

### Step 4 — Make the edit

Apply your intended change using `Edit` or `Write`. When replacing a complete
function or method body, `replace_symbol_body` is an option that resolves the
symbol by name and replaces its full range without position math:

```
mcp__lsp__replace_symbol_body({
  "file_path": "<definition file>",
  "symbol_path": "ExportedFunction",
  "new_body": "<new full definition>"
})
```

For other edits (signature changes, partial modifications), use `Edit` or `Write`.
Follow the standard edit workflow for the language. If renaming, update all call
sites identified in step 2 as well; do not leave broken callers.

Collect diagnostics **before** the edit so you have a baseline for comparison
in step 5:

```
mcp__lsp__get_diagnostics({
  "file_path": "<definition file>"
})
```

Then apply the edit and collect diagnostics again after.

### Step 5 — Check diagnostics

Compare before and after diagnostic snapshots using the format in
[references/patterns.md](references/patterns.md).

If new errors appear, fix them before proceeding. Do not run the build with
known diagnostic errors outstanding.

### Step 6 — Run the build

```
mcp__lsp__run_build({
  "workspace_root": "/abs/path/to/repo"
})
```

A clean build confirms no compilation errors across all affected packages.
If the build fails, diagnose using the error output and diagnostic data from
step 5. Fix and re-run until the build passes.

### Step 7 — Report

Emit the final output block:

```
## Edit Summary
- Symbol: <name> (<kind>)
- Callers found: N in M files
- Diagnostics: net +N/-N
- Build: PASSED / FAILED
```

If build is FAILED, include the first 3–5 error lines and a brief diagnosis.

## Example

```
Goal: rename exported function `ParseConfig` → `LoadConfig` in pkg/config

Step 1 — go_to_symbol: symbol_path="config.ParseConfig"
  → pkg/config/parser.go:42:6

Step 2 — find_references: position_pattern="func @@ParseConfig("
  → 7 references in 4 files

Step 3 — gate:
  ## Impact Check: ParseConfig
  - Definition: pkg/config/parser.go:42
  - Callers found: 7 in 4 files
  Files: cmd/main.go, internal/app.go, internal/loader.go, pkg/config/parser_test.go
  Proceed? [y/n] → y

Step 4 — edit: rename declaration + all 7 call sites

Step 5 — diagnostics: net 0 (no new errors)

Step 6 — build: PASSED

Step 7 — report:
  ## Edit Summary
  - Symbol: LoadConfig (function)
  - Callers found: 7 in 4 files
  - Diagnostics: net 0
  - Build: PASSED
```

## Note on position_pattern

`position_pattern` with `@@` is a agent-lsp extension. If your MCP client
or server does not support it, fall back to explicit `line` and `column`
parameters from the location returned by `go_to_symbol` in step 1.

© blackwell-systems · MIT · blackwell-systems/agent-lsp

Similar skills

All skills for Code review and refactoring →

From the same set25

lsp-fix-all Walks every diagnostic in a file and applies the quick-fixes your language server offers. Handy when errors and warnings have piled up before you start new work. CX Codex +1 ★ 165repo stars lsp-extract-function Extracts selected code blocks into named functions via LSP code actions or manual AST fallback. Validates scopes, arguments, and compilation diagnostics. CX Codex +1 ★ 165repo stars lsp-explore Inspect a symbol’s definition, type details, implementations, callers, and references in one report. Useful when you’re finding your way around an unfamiliar codebase. CX Codex +1 ★ 165repo stars lsp-edit-symbol Changes a function, type or variable by name when you don't know the file or position. Runs on the agent-lsp MCP server. CX Codex +1 ★ 165repo stars lsp-docs This skill looks up symbol details through LSP, local toolchain docs, then source code. Use it when hover has little to show or a dependency is not indexed. CX Codex +1 ★ 165repo stars lsp-dead-code The skill lists exported symbols in a file and checks each one for references across the workspace. Useful when you want to know which exports are safe to drop. CX Codex +1 ★ 165repo stars lsp-cross-repo Locates callers of a library symbol across consumer repositories via LSP. Useful when preparing to refactor or remove shared code without breaking dependents. CX Codex +1 ★ 165repo stars lsp-concurrency-audit This skill checks how a type’s or file’s fields are accessed across concurrent contexts and produces a safety report. Use it before refactoring or when investigating possible data races. CX Codex +1 ★ 165repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor