smithery.ai

lsp

How the atopile Language Server works (pygls), how it builds per-document graphs for completion/hover/defs, and the invariants for keeping it fast and crash-proof.

First seen Apr 3, 2026

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,375 B
  • docs SUMMARY.md 174 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1 installs

SKILL.md

LSP Module

The lsp module (located in src/atopile/lsp/) implements the Language Server Protocol for atopile. It provides IDE features like autocomplete, go-to-definition, and diagnostics (error reporting) for ato files.

Quick Start

Run the server on stdio (what editors expect):

python -m atopile.lsp.lsp_server

Relevant Files

  • Server implementation: src/atopile/lsp/lsp_server.py

- owns global LSPSERVER (pygls LanguageServer) - maintains per-document DocumentState (graph/typegraph/buildresult) - implements completion/hover/definition/diagnostics handlers

  • Utilities: src/atopile/lsp/lsp_utils.py
  • Optional debugging helper: src/atopile/lsp/debugserver.py

Dependants (Call Sites)

  • VSCode Extension: The designated client for this server.
  • Compiler: The LSP invokes the compiler (often in a partial or fault-tolerant mode) to understand the code structure.

How to Work With / Develop / Test

Core Concepts

  • Partial Compilation: Unlike the CLI build, the LSP must handle broken or incomplete code without crashing.
  • Latency: Features must be fast (<50ms for typing, <200ms for completion).
  • Per-document graphs: each open document has an isolated GraphView + TypeGraph stored in DocumentState.
  • Keep last good build: the server keeps the last successful BuildFileResult to power completion/hover even when the current edit has errors.

Development Workflow

  1. Edit handlers/helpers in src/atopile/lsp/lsp_server.py.
  2. Run completion tests (fast loop) and verify GraphView cleanup paths.

Testing

  • Integration-style tests: ato dev test --llm test/testlspcompletion.py -q

Best Practices

  • Robustness: Never let the server crash. Catch all exceptions in handlers and log them.
  • Debouncing: Don't trigger expensive operations on every keystroke.

Core Invariants (easy to regress)

  • Always destroy old graphs on rebuild/reset (DocumentState.reset_graph calls GraphView.destroy()).
  • Do not assume builds succeed; most features must handle:

- syntax errors (ANTLR) - partial typegraphs - exceptions from linking/deferred execution