lsp-implement

$npx mdskill add blackwell-systems/agent-lsp/lsp-implement

> Requires the agent-lsp MCP server.

SKILL.md

.github/skills/lsp-implementView on GitHub ↗
---
name: lsp-implement
description: Find all concrete implementations of an interface or abstract type. Use when you need to know what types satisfy an interface, or what subtypes exist before changing a base type.
argument-hint: "[interface-or-type-name]"
user-invocable: true
allowed-tools: mcp__lsp__start_lsp mcp__lsp__get_server_capabilities mcp__lsp__go_to_symbol mcp__lsp__go_to_implementation mcp__lsp__type_hierarchy mcp__lsp__open_document
license: MIT
compatibility: Requires the agent-lsp MCP server (github.com/blackwell-systems/agent-lsp)
metadata:
  required-capabilities: implementationProvider
  optional-capabilities: typeHierarchyProvider workspaceSymbolProvider
---

> Requires the agent-lsp MCP server.

# lsp-implement

Find every concrete type that implements an interface, or every subtype of an
abstract type. Read-only — does not modify any files.

Use this skill **before** changing an interface signature, adding a method to
an interface, or removing a base-type method. It tells you every type that
must be updated.

**Invocation:** User provides `type_name` (e.g. `"Handler"`, `"io.Reader"`).
Optionally provide `workspace_root`.

---

## Prerequisites

Check server capabilities — `go_to_implementation` and `type_hierarchy` are
optional features not implemented by all language servers:

```
mcp__lsp__get_server_capabilities()
```

Note which of `go_to_implementation` and `type_hierarchy` appear in
`supported_tools`. The steps below depend on this result.

If neither is supported, report `"Server does not support implementation
lookup"` and stop.

---

## Step 1 — Locate the interface or type

```
mcp__lsp__go_to_symbol({
  "symbol_path": "<TypeName>",
  "workspace_root": "/abs/path"   // optional
})
→ returns: file, line, column (1-indexed)
```

Open the file so the language server tracks it:

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

Record `file`, `line`, `column` for subsequent steps.

---

## Step 2 — Find all implementations

Only if `go_to_implementation` appears in `supported_tools`.

```
mcp__lsp__go_to_implementation({
  "file_path": "<file>",
  "line": <line>,
  "column": <column>
})
```

Returns a list of locations — each is a concrete type that satisfies the
interface. Group by file. Record type names and locations.

If `go_to_implementation` is **not** supported: skip; note in report.

---

## Step 3 — Type hierarchy (subtypes and supertypes)

Only if `type_hierarchy` appears in `supported_tools`.

```
mcp__lsp__type_hierarchy({
  "file_path": "<file>",
  "line": <line>,
  "column": <column>,
  "direction": "subtypes"   // use "both" to also see what this type extends
})
```

`subtypes` returns concrete types that extend or embed this type.
`supertypes` returns what this type itself implements.

Cross-reference with Step 2 results — the union gives the complete
implementation surface.

If `type_hierarchy` is **not** supported: skip; note in report.

---

## Step 4 — Report

```
## Implementation Report: <TypeName>

### Definition
- File: <file>:<line>
- Kind: interface / abstract type / base struct

### Concrete Implementations (<N> found)
- TypeA — <file>:<line>
- TypeB — <file>:<line>
...

### Type Hierarchy
Supertypes: [list or "none"]
Subtypes: [list or "same as implementations above" or "not supported"]

### Risk Assessment
| N implementations | Recommendation |
|---|---|
| 0 | Interface unused or no external implementors found. May be internal-only. |
| 1–3 | Low risk. All implementors can be updated together. |
| 4–10 | Medium risk. Plan updates package by package. |
| > 10 | High risk. Changing the interface is a breaking API change. |
```

---

## Common use cases

**Before adding a method to an interface:**
Run lsp-implement to find all types that will need the new method. Each
implementation site must be updated — this is your required change list.

**Before removing a method:**
Find all types that implement it. Check whether any external (outside this
repo) packages may be affected.

**Understanding polymorphism in an unfamiliar codebase:**
Run lsp-implement on the primary interface to see the full type hierarchy
before making any changes.

---

## Language notes

| Language | `go_to_implementation` finds... |
|---|---|
| Go | All types with matching method sets |
| TypeScript | All classes implementing the interface |
| Java/C# | All classes/structs implementing the interface |
| Rust | All structs with `impl Trait for ...` |

For Go: `go_to_implementation` on an interface finds all types that satisfy
it, even without an explicit `implements` declaration.

More from blackwell-systems/agent-lsp

SkillDescription
lsp-architectureGenerate a structural architecture overview of a codebase: languages, package map, entry points, dependency graph, and hotspots. One call for the big picture.
lsp-concurrency-auditConcurrency safety audit for a type or file. Maps all fields, traces which are accessed from concurrent contexts (goroutines, threads, async tasks), and flags fields that lack synchronization. Produces a field-level safety report. Language-agnostic across 4 concurrency families.
lsp-cross-repoCross-repository analysis — find all callers of a library symbol in one or more consumer repos. Use when refactoring a shared library and need to understand how consumers use it.
lsp-dead-codeEnumerate exported symbols in a file and surface those with zero references across the workspace. Use when auditing for dead code, cleaning up APIs, or checking which exports are safe to remove.
lsp-docsThree-tier documentation lookup for any symbol — hover → offline toolchain doc → source definition. Use when hover text is absent, insufficient, or the symbol is in an unindexed dependency.
lsp-edit-exportSafe 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.
lsp-edit-symbolEdit a named symbol without knowing its file or position. Use when you want to change a function, type, or variable by name and don't have exact coordinates. Resolves the symbol to its definition, retrieves its full range, and applies the edit.
lsp-explore"Tell me about this symbol": hover + implementations + call hierarchy + references in one pass — for navigating unfamiliar code.
lsp-extract-functionExtract a selected code block into a named function. Primary path uses the language server's extract-function code action; falls back to manual extraction when no code action is available. Validates captured variables, scope shadowing, and compilation after extraction.
lsp-fix-allApply available quick-fix code actions for all current diagnostics in a file, one at a time with re-collection between each fix. Use to bulk-resolve errors and warnings the language server can fix automatically.