Skip to main content
skill CX Codex

lsp-explore — Claude Code skill for code navigation

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.

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

What lsp-explore does

Give the skill a symbol in dot notation, such as codec.Encode. It locates the definition, opens its file, retrieves hover information, and gathers implementation locations, incoming calls, and references. References are grouped by file and counted in the final report.

The workflow uses tools from the agent-lsp MCP server. If LSP has not started, the skill initializes it for the workspace first. It checks server capabilities before searching for implementations or callers, so those sections depend on LSP support. The MCP server is required, and the skill does not modify files.

What it helps with

  • locate a symbol’s definition
  • inspect a symbol’s type and documentation
  • trace incoming function calls
  • find implementations of a method
  • collect references grouped by file

Example prompts for the agent

  • Explain codec.Encode and show its callers and references.
  • Find the definition and implementations of Buffer.Reset in this project.
  • Explore config.ParseConfig from the current workspace.

How to install lsp-explore

1Skills CLI (Vercel)

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

2Manually: put the files in place

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

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

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

Questions about lsp-explore

How do I install lsp-explore in Claude Code?

Run npx skills add blackwell-systems/agent-lsp --skill lsp-explore -a claude-code. The skill file is available at ~/.claude/skills/lsp-explore/SKILL.md.

What does lsp-explore do?

It locates a symbol and reports its definition, hover details, implementations, incoming callers, and references. It leaves project files unchanged.

What does lsp-explore need to run?

It requires the agent-lsp MCP server. Implementation and caller searches depend on the capabilities exposed by the LSP server.

Source text

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

Similar skills

All skills for Programming languages →

From the same set25

lsp-generate Triggers language server code generation for interface stubs, test skeletons, and missing methods. Useful when scaffolding new types or missing symbols. CX Codex +1 ★ 165repo stars lsp-format-code Formats an entire source file or a selected line range through a language server. Use it to tidy generated code or apply the project's formatting rules before a commit. CX Codex +1 ★ 165repo stars 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-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-edit-export A guided workflow for editing exported symbols and public APIs. It finds every caller via LSP, pauses for explicit confirmation, and verifies the build. 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

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