К основному содержанию
скилл CX Codex

lsp-explore — скилл для Claude Code: навигация по коду

Собирает сведения о символе: определение, тип, реализации, вызывающие функции и ссылки. Пригодится, когда нужно разобраться в незнакомом коде.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add blackwell-systems/agent-lsp --skill lsp-explore -a claude-code
Открыть на GitHub

Что делает lsp-explore

Скилл находит символ по имени в точечной записи, например codec.Encode, и открывает файл с его определением. Затем запрашивает сведения о типе и документации, ищет реализации, входящие вызовы и места использования. Ссылки группирует по файлам и считает; результат оформляет как отчёт.

Работа идёт через инструменты agent-lsp: если LSP ещё не запущен, скилл сначала инициализирует его для корня проекта. По возможностям сервера проверяет, доступны ли поиск реализаций и вызывающих функций. Поиск доступен только при установленном MCP-сервере agent-lsp; скилл не меняет файлы.

Какие задачи решает

  • найти определение символа в проекте
  • узнать тип и документацию символа
  • проследить входящие вызовы функции
  • найти реализации метода
  • собрать ссылки на символ по файлам

Примеры запросов агенту

  • Разберись, что делает символ codec.Encode, и покажи его вызовы и ссылки.
  • Найди определения и реализации Buffer.Reset в этом проекте.
  • Исследуй символ config.ParseConfig в корне текущего проекта.

Как установить lsp-explore

1Через Skills CLI (Vercel)

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

2Вручную: положить файлы

~/.claude/skills/lsp-explore/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/lsp-explore/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Вопросы о lsp-explore

Как установить lsp-explore в Claude Code?

Выполните npx skills add blackwell-systems/agent-lsp --skill lsp-explore -a claude-code. Файл скилла будет доступен по пути ~/.claude/skills/lsp-explore/SKILL.md.

Что делает lsp-explore?

Находит символ и собирает в один отчёт сведения о нём, реализациях, вызывающих функциях и ссылках. Файлы остаются без изменений.

Что нужно для работы lsp-explore?

Нужен MCP-сервер agent-lsp. Поиск реализаций и входящих вызовов зависит от того, поддерживает ли их LSP-сервер.

Исходный текст

SKILL.md · MIT
---
name: lsp-explore
description: '"Tell me about this symbol": hover + implementations + call hierarchy + references in one pass — for navigating unfamiliar code.'
argument-hint: "[symbol-name]"
user-invocable: true
allowed-tools: mcp__lsp__start_lsp mcp__lsp__go_to_symbol mcp__lsp__inspect_symbol mcp__lsp__go_to_implementation mcp__lsp__find_callers mcp__lsp__find_references mcp__lsp__open_document mcp__lsp__get_server_capabilities
license: MIT
compatibility: Requires the agent-lsp MCP server (github.com/blackwell-systems/agent-lsp)
metadata:
  required-capabilities: hoverProvider
  optional-capabilities: implementationProvider callHierarchyProvider referencesProvider
---

> Requires the agent-lsp MCP server.

# lsp-explore

"Tell me about this symbol" — hover, implementations, call hierarchy, and
references in a single pass. Use when navigating unfamiliar code: you get
type info, doc comments, who calls it, what implements it, and every
reference site without issuing four separate commands.

Read-only — does not modify any files.

**Invocation:** User provides a symbol name in dot notation (e.g.
`"codec.Encode"`, `"Buffer.Reset"`). Optionally provide `workspace_root`
to scope the search.

---

## Prerequisites

If LSP is not yet initialized, call `mcp__lsp__start_lsp` with the workspace
root first. Auto-inference applies when file paths are provided.

---

## Phase 1 — Locate the symbol

Call `mcp__lsp__go_to_symbol` with `symbol_path` set to the user-provided name:

```
mcp__lsp__go_to_symbol({
  "symbol_path": "Package.SymbolName",   // dot notation; e.g. "codec.Encode"
  "workspace_root": "<root>"             // optional
})
→ returns: file, line, column (1-indexed)
```

Record the returned `file`, `line`, and `column`. If `go_to_symbol` returns
nothing, report:

> Symbol not found: `<name>`
> Check the dot-notation path (e.g. "Package.Symbol") and ensure the workspace
> root covers the file.

Stop immediately — do not proceed to Phase 2.

Then open the file so the language server has it in view:

```
mcp__lsp__open_document({
  "file_path": "<file from go_to_symbol>"
})
```

---

## Phase 2 — Hover (always available)

Call `mcp__lsp__inspect_symbol` at the definition location:

```
mcp__lsp__inspect_symbol({
  "file_path": "<file from Phase 1>",
  "line": <line from Phase 1>,
  "column": <column from Phase 1>
})
```

Store the result as `hover_text`. If the call fails or returns nothing, set
`hover_text` to an empty string. Do not stop.

---

## Phase 3 — Implementations (capability-gated)

Call `mcp__lsp__get_server_capabilities` to see what the server supports:

```
mcp__lsp__get_server_capabilities()
→ returns: supported_tools list
```

If `go_to_implementation` appears in `supported_tools`, call it:

```
mcp__lsp__go_to_implementation({
  "file_path": "<file from Phase 1>",
  "line": <line from Phase 1>,
  "column": <column from Phase 1>
})
→ returns: list of implementation locations (file, line)
```

Record locations as `implementations`. If `go_to_implementation` is **not**
in `supported_tools`, record `"not supported by this server"` — do not stop.

---

## Phase 4 — Call hierarchy and references (run in parallel)

Issue both calls in the same message — they are independent:

### 4a — Incoming callers

Only if `find_callers` appears in `supported_tools`:

```
mcp__lsp__find_callers({
  "file_path": "<file from Phase 1>",
  "line": <line from Phase 1>,
  "column": <column from Phase 1>,
  "direction": "incoming"
})
→ returns: list of caller functions with file and line
```

If `find_callers` is **not** in `supported_tools`, note
`"not supported by this server"` — do not stop.

### 4b — All reference sites

```
mcp__lsp__find_references({
  "file_path": "<file from Phase 1>",
  "line": <line from Phase 1>,
  "column": <column from Phase 1>,
  "include_declaration": false
})
→ returns: list of reference locations (file, line)
```

Collect all reference locations. Group by file and count distinct files.

---

## Output format — Explore Report

Produce the report in this format:

```
## Explore Report: <SymbolName>

### Definition
- File: <file>:<line>
- Hover: <hover_text or "unavailable">

### Implementations (<N> found, or "not supported")
[list of file:line entries, or "none found", or "not supported by this server"]

### Callers (incoming call hierarchy)
[list of caller function names with file:line, or "none", or "not supported"]

### References (<N> total across <M> files)
[list of file:line entries grouped by file, or "none found"]

### Summary
- Symbol kind:      <inferred from hover or "unknown">
- Reference count:  <N>
- Files with refs:  <M distinct files>
- Callers:          <K>
- Implementations:  <P or "not supported">
```

Keep the report concise. The goal is "understand this symbol in one pass."

---

## Example

```
Goal: understand the exported function `ParseConfig` in pkg/config

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

open_document: pkg/config/parser.go

Phase 2 — inspect_symbol: line=42, column=6
  → hover_text: "func ParseConfig(path string) (*Config, error) — reads and
    validates a config file from path"

Phase 3 — get_server_capabilities
  → go_to_implementation: in supported_tools
  go_to_implementation: line=42, column=6
  → 0 implementations (ParseConfig is a concrete function, not an interface method)

Phase 4 (parallel):
  find_callers direction=incoming
  → 3 callers: cmd.main (cmd/main.go:14), app.Start (internal/app.go:31),
               loader.Load (internal/loader.go:55)

  find_references include_declaration=false
  → 7 references in 4 files

## Explore Report: ParseConfig

### Definition
- File: pkg/config/parser.go:42
- Hover: func ParseConfig(path string) (*Config, error) — reads and validates a
  config file from path

### Implementations (0 found)
none found

### Callers (incoming call hierarchy)
- cmd.main — cmd/main.go:14
- app.Start — internal/app.go:31
- loader.Load — internal/loader.go:55

### References (7 total across 4 files)
cmd/main.go: line 14
internal/app.go: lines 31, 87
internal/loader.go: line 55
pkg/config/parser_test.go: lines 12, 34, 56, 78

### Summary
- Symbol kind:      function
- Reference count:  7
- Files with refs:  4
- Callers:          3
- Implementations:  0
```

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

Похожие скиллы

Все скиллы по теме «Языки программирования» →
migrate-to-shoehorn Matt Pocock Переводит type assertions с as в тестах на функции из @total-typescript/shoehorn. Нужен для частичных объектов и намеренно неверных данных в проверках. 475 388установок write-swift emilkowalski Скилл помогает писать, проверять и переносить код на Swift с учётом модели языка. Подойдёт, когда нужно разобраться с конкурентностью, ошибкой или циклом удержания объектов. CX Codex +1 119 300установок megacave JuliusBrussee Переводит ответы ассистента на классический китайский язык (вэньянь) для экономии места на экране. Активируется командами /megacave или /caveman wenyan. CX Codex +1 25 400установок find-docs upstash Тянет актуальную документацию, справочники API и примеры кода для любой библиотеки через Context7 CLI. Пригодится, когда агент отвечает по устаревшим данным обучения. CX Codex +1 9 400установок typescript-advanced-types Seth Hobson Помогает агенту писать сложную типизацию TypeScript: generics, conditional types и преобразования типов. Нужен для библиотек, API-клиентов и строгих конфигураций. CX Codex 92 169установок smart-explore thedotmack Структурно ищет функции и классы через tree-sitter. Пригодится, когда нужно разобраться в кодовой базе без чтения всех файлов. CX Codex +1 7 300установок

Из того же набора25

lsp-generate Запускает генерацию кода через языковой сервер: создаёт заглушки интерфейсов, каркасы тестов и недостающие методы. Пригодится при написании нового кода по типам. CX Codex +1 ★ 165звёзд репо lsp-format-code Форматирует целый файл или выбранный диапазон через языковой сервер. Пригодится после генерации кода и перед коммитом, чтобы привести отступы и стиль к правилам проекта. CX Codex +1 ★ 165звёзд репо lsp-fix-all Прогоняет все диагностики в файле и применяет доступные quick-fix от языкового сервера. Пригодится, когда в файле накопились ошибки и предупреждения перед новой работой. CX Codex +1 ★ 165звёзд репо lsp-extract-function Выносит выделенный блок кода в отдельную функцию через LSP-сервер или вручную. Помогает безопасно декомпозировать функции с проверкой типов и скоупа. CX Codex +1 ★ 165звёзд репо lsp-edit-symbol Меняет функцию, тип или переменную по имени, когда точный файл и позиция неизвестны. Работает через MCP-сервер agent-lsp. CX Codex +1 ★ 165звёзд репо lsp-edit-export Пошаговый сценарий безопасного изменения публичных функций, типов и API. Сначала находит все вызовы через LSP, запрашивает подтверждение и проверяет сборку. CX Codex +1 ★ 165звёзд репо lsp-docs Скилл ищет сведения о символе через LSP, документацию локального toolchain и исходное определение. Выручает, когда hover пустой или зависимость не индексируется. CX Codex +1 ★ 165звёзд репо lsp-dead-code Скилл перечисляет экспортируемые символы файла и проверяет каждый на ссылки по всему проекту. Помогает понять, какие экспорты можно удалять. CX Codex +1 ★ 165звёзд репо

Спонсоры проекта

Компании, которые помогают держать аналитику открытой