返回技能列表

lsp-edit-export

blackwell-systems
更新于 5 days ago
53
2
53
在 GitHub 上查看
开发apiautomation

关于

This skill provides a safe workflow for editing exported symbols or public APIs by first finding all callers to prevent silent breakages. It's designed for changes like modifying function signatures or public types that are used outside their package. The skill uses LSP tools to locate references, verify changes, and ensure clean modifications.

快速安装

Claude Code

推荐
主要方式
npx skills add blackwell-systems/agent-lsp -a claude-code
插件命令备选方式
/plugin add https://github.com/blackwell-systems/agent-lsp
Git 克隆备选方式
git clone https://github.com/blackwell-systems/agent-lsp.git ~/.claude/skills/lsp-edit-export

在 Claude Code 中复制并粘贴此命令以安装该技能

技能文档

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:

LanguageExported means...
GoIdentifier starts with an uppercase letter (e.g. MyFunc, MyType)
TypeScriptHas export keyword; or is a public class member (no private)
PythonNot prefixed with _; or explicitly listed in __all__
Java/C#Has public or protected visibility modifier
RustHas 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.

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.

GitHub 仓库

blackwell-systems/agent-lsp
路径: skills/lsp-edit-export
0
agentskillsai-agentsai-toolingclaudeclaude-codecode-intelligence

相关推荐技能

qmd

开发

这是一个本地搜索和索引的CLI工具,支持BM25、向量搜索和重排序功能。开发者可以用它快速索引本地文件(如Markdown文档)并进行混合搜索,特别适合代码库或文档的本地检索。它还提供MCP模式,能轻松集成到Claude开发环境中使用。

查看技能

subagent-driven-development

开发

该Skill用于在当前会话中执行包含独立任务的实施计划,它会为每个任务分派一个全新的子代理并在任务间进行代码审查。这种"全新子代理+任务间审查"的模式既能保障代码质量,又能实现快速迭代。适合需要在当前会话中连续执行独立任务,并希望在每个任务后都有质量把关的开发场景。

查看技能

mcporter

开发

mcporter Skill 让开发者能在Claude中直接管理和调用MCP服务器。它支持列出可用服务器、调用工具、处理OAuth认证以及管理服务器守护进程。开发者可以通过命令行式交互快速执行`mcporter list`查看服务器,或使用`mcporter call`直接调用工具,简化了MCP工作流程。

查看技能

adk-deployment-specialist

开发

这是一个用于部署和编排Google Vertex AI ADK智能体的Claude Skill,专为构建生产级多智能体系统而设计。它支持通过A2A协议进行智能体通信,提供代码执行沙箱和记忆库功能,并能处理智能体发现与任务提交。当开发者需要部署ADK智能体或编排多智能体协作时,可使用此Skill来简化Vertex AI Agent Engine的部署流程。

查看技能