LS

lsp-hover-testing

Headless testing of Dingo transpiler LSP hover functionality.

Install

mkdir -p .claude/skills/lsp-hover-testing && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/3050" && unzip -o skill.zip -d .claude/skills/lsp-hover-testing && rm skill.zip

Installs to .claude/skills/lsp-hover-testing

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Automated LSP hover validation for Dingo transpiler. Use when testing hover functionality, validating position mappings, checking for hover drift, or debugging LSP issues after sourcemap changes.
195 chars✓ has a “when” trigger
Intermediate

Key capabilities

  • Automate LSP hover validation for Dingo
  • Validate column and line mappings
  • Run headless regression tests for hover
  • Compare hover output against YAML specifications

How it works

The tool runs headless tests by sending LSP hover requests to the Dingo server and comparing the returned content against expected substrings defined in YAML files.

Inputs & outputs

You give it
YAML hover specifications and Dingo source files
You get back
Pass/fail test report with hover content

When to use lsp-hover-testing

  • Validating column and line mappings for hover
  • Testing hover drift after sourcemap changes
  • Creating regression tests for Dingo LSP
  • Debugging transpiler mapping issues

About this skill

LSP Hover Testing Skill

Automated headless testing of LSP hover functionality for the Dingo transpiler. Replaces manual VS Code hover checks with reproducible, CI-compatible tests.

When to Use This Skill

  • After making changes to sourcemap/position tracking code
  • When debugging hover issues reported by users
  • To validate that column/line mappings work correctly
  • Before committing changes to pkg/lsp/, pkg/sourcemap/, or pkg/transpiler/
  • To create regression tests for hover functionality

Quick Start

# Build the tools first
go build -o dingo ./cmd/dingo
go build -o editors/vscode/server/bin/dingo-lsp ./cmd/dingo-lsp
go build -o lsp-hovercheck ./cmd/lsp-hovercheck

# Run hover tests
./lsp-hovercheck --spec "ai-docs/hover-specs/*.yaml"

# Verbose output for debugging
./lsp-hovercheck --spec ai-docs/hover-specs/http_handler.yaml --verbose

Spec File Format

Create YAML specs in ai-docs/hover-specs/:

file: examples/01_error_propagation/http_handler.dingo

cases:
  - id: 1
    line: 55                    # 1-based line number
    token: userID               # Token to hover on
    occurrence: 1               # Which occurrence (default: 1)
    description: "LHS variable"
    expect:
      contains: "var userID string"      # Must contain substring
      # OR
      containsAny:                        # Any of these
        - "var userID"
        - "userID string"
      # OR
      allowAny: true                      # Accept any result (skip assertion)

Assertion Types

TypeDescriptionExample
containsMust contain substringcontains: "func foo"
containsAnyAny of listed substringscontainsAny: ["func", "method"]
notContainsMust not containnotContains: "error"
allowAnySkip assertion, just recordallowAny: true

Output Format

http_handler.yaml:
------------------------------------------------------------
1: works
2: works
3: expected "var r", got "func extractUserID..."
4: works

============================================================
Total: 3 passed, 1 failed

Creating New Test Specs

Step 1: Identify test positions

# Show line numbers
sed -n '50,70p' examples/01_error_propagation/http_handler.dingo | nl -ba

Step 2: Create spec file

cat > ai-docs/hover-specs/my_example.yaml << 'EOF'
file: examples/my_example/file.dingo

cases:
  - id: 1
    line: 10
    token: myFunction
    description: "Function name hover"
    expect:
      contains: "func myFunction"
EOF

Step 3: Run and iterate

./lsp-hovercheck --spec ai-docs/hover-specs/my_example.yaml --verbose

Debugging Failed Tests

When a test fails, check:

  1. Column position: Is the token found at the right column?
  2. Tab handling: Lines starting with tabs may have offset issues
  3. Transformed lines: Error prop lines map to different Go positions
  4. LSP readiness: Increase --retries if hover returns empty

Verbose debug output

./lsp-hovercheck --spec ai-docs/hover-specs/http_handler.yaml --verbose

Shows:

  • Exact LSP request/response JSON
  • Computed column positions
  • Hover content returned

Known Limitations

VS Code vs Automated Differences

The automated test may show different results than VS Code due to:

  • Tab character handling differences
  • LSP initialization timing
  • VS Code extension preprocessing

Current Behavior (2025-12-14)

Position TypeAutomated ResultVS Code Result
Function namesWorksWorks
Function argumentsWorksShows function sig (bug)
LHS variablesEmptyShows temp var (bug)

File Locations

FilePurpose
cmd/lsp-hovercheck/Hover check tool source
ai-docs/hover-specs/Test specification files
editors/vscode/server/bin/dingo-lspLSP server binary

CI Integration

Add to your CI pipeline:

- name: Build tools
  run: |
    go build -o dingo ./cmd/dingo
    go build -o editors/vscode/server/bin/dingo-lsp ./cmd/dingo-lsp
    go build -o lsp-hovercheck ./cmd/lsp-hovercheck

- name: Run hover tests
  run: ./lsp-hovercheck --spec "ai-docs/hover-specs/*.yaml"

Related Files

When not to use it

  • When relying on VS Code extension preprocessing for test results

Prerequisites

Go build environment

Limitations

  • Automated results may differ from VS Code due to tab handling
  • LSP initialization timing can affect test reliability

How it compares

It replaces manual VS Code hover verification with reproducible, CI-compatible automated testing.

Compared to similar skills

lsp-hover-testing side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
lsp-hover-testing (this skill)18moReviewIntermediate
go-dev-guidelines149moNo flagsIntermediate
code-formatting12moNo flagsBeginner
tidb-test-guidelines225dNo flagsIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

More by MadAppGang

View all by MadAppGang

claudish-usage

MadAppGang

CRITICAL - Guide for using Claudish CLI ONLY through sub-agents to run Claude Code with any AI model (OpenRouter, Gemini, OpenAI, local models). NEVER run Claudish directly in main context unless user explicitly requests it. Use when user mentions external AI models, Claudish, OpenRouter, Gemini, OpenAI, Ollama, or alternative models. Includes mandatory sub-agent delegation patterns, agent selection guide, file-based instructions, and strict rules to prevent context window pollution.

442

golang-performance

MadAppGang

Use when profiling Go applications (pprof), running benchmarks, optimizing memory/CPU usage, or debugging performance bottlenecks in production Go code.

47

golang

MadAppGang

Use when building Go backend services, implementing goroutines/channels, handling errors idiomatically, writing tests with testify, or following Go best practices for APIs/CLI tools.

313

schemas

MadAppGang

YAML frontmatter schemas for Claude Code agents and commands. Use when creating or validating agent/command files.

34

external-model-selection

MadAppGang

Choose optimal external AI models for code analysis, bug investigation, and architectural decisions. Use when consulting multiple LLMs via claudish, comparing model perspectives, or investigating complex Go/LSP/transpiler issues. Provides empirically validated model rankings (91/100 for MiniMax M2, 83/100 for Grok Code Fast) and proven consultation strategies based on real-world testing.

218

adr-documentation

MadAppGang

Architecture Decision Records (ADR) documentation practice. Use when documenting architectural decisions, recording technical trade-offs, creating decision logs, or establishing architectural patterns. Trigger keywords - "ADR", "architecture decision", "decision record", "trade-offs", "architectural decision", "decision log".

12

You might also like

go-dev-guidelines

jumppad-labs

This skill should be used when writing, refactoring, or testing Go code. It provides idiomatic Go development patterns, TDD-based workflows, project structure conventions, and testing best practices using testify/require and mockery. Activate this skill when creating new Go features, services, packages, tests, or when setting up new Go projects.

1495

code-formatting

openshift

MANDATORY: When writing Go tests, you MUST use 'When...it should...' format for ALL test names. When writing any Go code, you MUST remind user to run 'make lint-fix' and 'make verify'. These are non-negotiable HyperShift requirements.

112

tidb-test-guidelines

pingcap

Decide where to place TiDB tests and how to write them (basic structure, naming, testdata usage). Use when asked about test locations, writing conventions, shard_count limits, casetest categorization, or when reviewing test changes in code review.

210

go-rig

mudrii

Use this skill when building, reviewing, or refactoring Go code in this repository. It adds process discipline for TDD/ATDD, package boundaries, dependency injection, and review quality, and complements the always-on rules in AGENTS.md.

00

code-coverage

viknesh20-20

Analyzes test coverage, identifies untested code paths, and generates tests for the most critical uncovered areas. Use to improve test coverage before releases.

00

go-review-pr

JotJunior

Review all changes in the current branch against GOB project conventions before opening a PR. Diff-aware: only analyzes what changed, not the entire codebase. Triggers: \"review pr\", \"revisar pr\", \"pre-pr check\", \"review branch\", \"revisar branch\", \"checar antes do pr\", \"quality gate\".

00

Search skills

Search the agent skills registry