lsp-bench

Plugin lsp-bench from marketplace asyncswap in asyncswap/skills. Commands read from the repo's manifest — 4 days ago.

Skills (12)

• assert-results

  Verify the LSP response shape with `expect:`. Use when you want the bench to fail if the response shrinks, the wrong file resolves, or a specific completion item disappears.

• cold-vs-warm

  Manage how the LSP is run during a benchmark — restart it for every iteration (cold) or reuse one initialized session across iterations (warm). Use cold to measure what the user feels on first use; use warm to measure steady-state response cost.

• commands

  Invoke a server-defined command via `workspace/executeCommand`. Set `waitForProgress: true` if the command kicks off background work you want to include in the timing.

• custom-init-settings

  Send custom configuration to the LSP during `initialize` via `initializeSettings:`. Mirrors the editor's settings block — used to enable inlay hints, lint, file-operations, custom indexing modes, etc.

• evolve-the-file

  Run the same LSP method across a sequence of file edits via `didChange:` snapshots. Use when you want to see how a method's response changes as the file evolves — added callers, shifted positions, new modifier usages, etc.

• extra-files

  Open additional files mid-session via `didOpen:` and re-run the request on the original file. Use to test cross-file discovery — does the response grow as the LSP learns about more files?

• lifecycle-tests

  Test full file-rename / create / delete lifecycles via `renameFiles:`, `createFiles:`, and `deleteFiles:`. Each step exercises the LSP's request → apply edits → on-disk operation → notification → re-index cycle and restores the project at the end.

• methods

  Per-method config schema for every LSP method `lsp-bench` supports. Lists every key valid under each `methods.<method>:` block — required, optional, type, default. Use to validate what a method's config can or cannot do.

• multi-file

  Run the same LSP method against multiple `(file, line, col)` triples in one bench session via `batch:`. Use to perf-sweep across files, or to check references from different files / locations all return the same set.

• replay

  Re-issue a captured LSP request from a previous benchmark run against any server. Use to debug a single failing request without re-running the full bench, or to bisect a regression by replaying the same request against earlier server versions.

• setup

  Project layout, `servers.yaml` registry, and top-level config keys for `lsp-bench`. Use before writing per-method configs to set up shared bits (registry, common `initializeSettings`, `include:` composition); reference when the user asks "where do I configure servers" or "how do I bench against mult

• wait-for-token

  Make the bench wait for a specific LSP `$/progress` token before sending the request, or wait for a progress token to end *after* the response. Use when the request depends on background work (project indexing, sub-cache loading, custom build steps).

Similar plugins