lsp-edit-export
정보
이 스킬은 내보낸 심볼이나 공개 API를 수정할 때, 무음 오류를 방지하기 위해 모든 호출자를 먼저 찾는 안전한 작업 흐름을 제공합니다. 이는 함수 시그니처나 패키지 외부에서 사용되는 공개 타입과 같은 변경 작업을 위해 설계되었습니다. LSP 도구를 사용하여 참조 위치를 찾고, 변경 사항을 검증하며, 깔끔한 수정을 보장합니다.
빠른 설치
Claude Code
추천npx skills add blackwell-systems/agent-lsp -a claude-code/plugin add https://github.com/blackwell-systems/agent-lspgit clone https://github.com/blackwell-systems/agent-lsp.git ~/.claude/skills/lsp-edit-exportClaude 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:
| 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.
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 저장소
연관 스킬
qmd
개발qmd는 BM25, 벡터 임베딩, 재순위화를 결합한 하이브리드 검색을 통해 로컬 파일을 색인화하고 검색할 수 있는 로컬 검색 및 색인화 CLI 도구입니다. 명령줄 사용과 Claude 통합을 위한 MCP(Model Context Protocol) 모드를 모두 지원합니다. 이 도구는 임베딩에 Ollama를 사용하고 색인을 로컬에 저장하여 터미널에서 직접 문서나 코드베이스를 검색하는 데 이상적입니다.
subagent-driven-development
개발이 스킬은 각 독립적인 작업마다 새로운 하위 에이전트를 배치하고 작업 사이에 코드 리뷰를 진행하여 구현 계획을 실행합니다. 이 리뷰 프로세스를 통해 품질 게이트를 유지하면서 빠른 반복 작업을 가능하게 합니다. 동일한 세션 내에서 대부분 독립적인 작업을 진행할 때 내장된 품질 검증과 함께 지속적인 진행을 보장하기 위해 사용하세요.
mcporter
개발mcporter 스킬은 개발자가 Claude에서 직접 Model Context Protocol(MCP) 서버를 관리하고 호출할 수 있도록 합니다. 이 스킬은 사용 가능한 서버를 나열하고, 인수를 사용해 해당 서버의 도구를 호출하며, 인증 및 데몬 생명주기를 처리하는 명령어를 제공합니다. 개발 워크플로우에서 MCP 서버 기능을 통합하고 테스트할 때 이 스킬을 사용하세요.
adk-deployment-specialist
개발이 스킬은 A2A 프로토콜을 사용하여 Vertex AI ADK 에이전트를 배포하고 오케스트레이션하며, AgentCard 검색, 작업 제출, 코드 실행 샌드박스 및 메모리 뱅크와 같은 지원 도구를 관리합니다. Python, Java 또는 Go 언어로 순차, 병렬 또는 루프 오케스트레이션 패턴을 갖춘 다중 에이전트 시스템 구축을 가능하게 합니다. Google Cloud에서 ADK 에이전트 배포 또는 에이전트 워크플로우 오케스트레이션을 요청받았을 때 사용하세요.
