Using Claude Code to create skills, commands, plans, ... for SWI-Prolog

EricGT · December 7, 2025, 7:05pm

For the past few weeks, I’ve been using Claude Code for VS Code to program in SWI-Prolog with more success than failure.

Over the years, many developers have had limited success using LLMs from companies such as OpenAI, Anthropic, Google, and Meta to assist with Prolog coding, more specifically, SWI-Prolog.

I’m seeking to connect with others who are working not just with the LLM itself, but more specifically with skills, and to a lesser extent plan mode for creating plans and slash commands for use with Claude Code.

My Current Project

The project includes several main Prolog files (*.pl) and many corresponding tests (*.plt) with test fixtures. It also uses some less common SWI-Prolog libraries such as library(persistency) and library(prolog_coverage).

I’ve created a few basic slash commands for Git to handle common tasks related to branching and merging, as well as to help Claude locate swipl (since the path isn’t stored in my Windows PATH environment variable).

I’ve developed around 50 skills, some of which are worth their weight in gold—particularly with test Use Module Qualification for Internals. That is something that initial training for LLMs did not seem to learn, thus the skill augments the initial knowledge.

I should note that I’m no expert on using Claude, but I do manage to consistently become more effective with continued usage and understanding.

If you’re using Claude in a similar manner or want to learn more, please join the discussion!

EricGT · December 8, 2025, 3:56pm

If you are interested in using skills and do not use Claude Code then this GitHub repo might bridge the gap

e.g. to use with Codex

https://github.com/obra/superpowers/blob/154d664373569a83289684d7b01742a82cca4eaf/docs/README.codex.md

Note: I have not used this repo, it does have 9K+ stars.

If you want a challenge for your fist AI skill for use with SWI-Prolog, which is one that I’ve had some success, try getting generated SWI-Prolog code to correctly use the appropriate comparison operator when needed (e.g., for conditionals, assertions, etc.) and to use unification when appropriate.

Note, I would not be surprised if this skill will have to be specialized for different LLM models. This is one of the reasons to discuss these with others.

Have been using Claude Sonnet 4.5 mostly for SWI-Prolog coding with success. Switching to Haiku 4.5 was a disaster, it actually gave up on something that I thought was simple and switched to using Bash. Opus 4.5 works but expect to see the token usage jump significantly.

One of my hopes with all the skills is to give even Haiku 4.5 enough extra SWI-Prolog knowledge to create SWI-Prolog code. Many of the same problems keep reemerging and skills should/can be used to resolve them, just have to keep pushing forward.

Opus - Most capable for complex work.
Sonnet - Best for everyday tasks.
Haiku - Fastest for quick answers.

To track token usage with Claude, using the web chat interface or the desktop app, in the lower left click on the account icon, typically a circle with a letter in the middle. Then click Settings, then Usage.

EricGT · December 10, 2025, 1:24pm

In working with AI, which I include both Prolog and LLMs in such a set, it pays to understand that how humans problem solve and AI problem solve at times are similar and at times are different.

Many know about apropos/1 and help/1 in SWI-Prolog but may prefer to use the full documentation first. However if one has worked with Claude Code one will quickly see how often it uses basic low level command line tools, e.g. grep, repgrep, glob, bash, to accomplish finding needed information quickly and effectively. In that same light the use of apropos/1 and help/1 are also of value as a skill for Claude Code.

However those tools are designed to output information for human use and an AI often gets by on just the facts. For example in looking for meta-predicates, if there were a separate AI tool to just list the signature it could go a long way to saving many tokens.

Instead of giving this to the AI

catch(:Goal, +Catcher, :Recover)                                                           [ISO]
    Behaves as call/1 if no exception is raised when executing Goal. If  an exception  is raised
    using throw/1 while Goal executes,  and the  Goal is  the innermost  goal for  which Catcher
    unifies with the  argument of  throw/1, all  choice points  generated by  Goal are  cut, the
    system backtracks to the start of catch/3 while  preserving the  thrown exception  term, and
    Recover is called as in call/1.

    As  of  version  9.3.13,  constraints (attributed  variables) in  Catcher are  respected. If
    evaluating the constraint raises an exception, the most urgent  exception is  preserved (see
    section 4.10.2) and searching for a matching catch/3 call is  continued. If  both exceptions
    are equally urgent, the exception raised by the constraint evaluation is preserved.

    The overhead of calling a goal through  catch/3 is  comparable to  call/1. Recovery  from an
    exception is much  slower, especially  if the  exception term  is large  due to  the copying
    thereof or is decorated with a stack  trace using,  e.g., the  library library(prolog_stack)
    based on the prolog_exception_hook/5 hook predicate to rewrite exceptions.
true.

just give it this

catch(:Goal, +Catcher, :Recover)

Currently creating a Claude code script based on this idea.

jan · December 11, 2025, 9:03am

There are two things that may help:

?- man_object_property(Obj, summary(Summary)).

which you get from library(pldoc/man_index). This gives you the short summaries.

Then, SWISH provides lib/template_hint.pl, which provides man_predicate_info/2. The file is nearly stand-alone in SWISH. It might be worthwhile to move this part of the functionality to PlDoc? It is used to support SWISH template hinting, but that is of course something that can be useful for every development tool.

This is interesting work. As a side note, do you know whether Claude code integration uses the LSP protocol? I’m currently adding support to Prolog’s development tools to act as LSP client. The original aim of this is to be able to add external tooling for AI completion, spell checking, etc. For debug the interaction I now use it with clangd to enhance the C mode of the editor. That works remarkably well

EricGT · December 11, 2025, 12:22pm

In short, yes it is possible.

Using LSP with LLMs is quite common. Claude Code ~~doesn’t use LSP directly~~ (see reply below), but LSP can be integrated with Claude Code through extension mechanisms such as MCP (Model Context Protocol).

TL;DR

Your question is excellent and was one of the first things I explored when considering SWI-Prolog development with Anthropic Claude Code.

AFAIK, there is no built-in integration of an LSP server with Claude Code.

Search of Claude Code source for LSP

I searched the GitHub Anthropic Claude Code repository and found a reference to LSP: claude-code/plugins/plugin-dev/commands/create-plugin.md at ace0a827787630fd23857b43c3e63bba12bb57d3 · anthropics/claude-code · GitHub

Claude Code does provide ways to add more tools such as MCP:

Give Claude more tools

Claude has access to your shell environment, where you can build up sets of convenience scripts and functions for it just like you would for yourself. It can also leverage more complex tools through MCP and REST APIs.

Source: https://www.anthropic.com/engineering/claude-code-best-practices

Real-world example

The Lean 4 programming language has an LSP implementation via MCP that is part of the recommended setup:

MCP server: GitHub - oOo0oOo/lean-lsp-mcp: Lean Theorem Prover MCP

For using all of this with Claude Code Agent Skills

Skills integration: GitHub - cameronfreer/lean4-skills: Claude skills for Lean 4 theorem proving

My experience with SWI-Prolog and Claude Code

After exploring the LSP specification, I found that while LSP is valuable for human-in-the-loop coding, it wasn’t essential for my current workflow. Anthropic’s Sonnet and Opus models are quite capable of:

Generating complete SWI-Prolog source files
Compiling code and fixing compilation errors
Running code and addressing runtime errors

In practice, my workflow is: create a detailed Plan with significant human input, approve the plan, then let Claude Code work autonomously while manually reviewing each edit to verify the reasoning and catch any errors early.

I also asked Claude directly about LSP integration with Claude Code, and it confirmed that an MCP bridge is the preferred approach.

Example of Claude fixing run time bug

Screen capture of Claude Code hitting a run time error, thinking about it, identifying a fix, proposing a code change and asking to make the edit.

Note: In the prompt for creating the plan and the same conversation with the fix was

fetch: https://www.swi-prolog.org/pldoc/man?section=consulting

so that Claude would have that knowledge in the context window. I suspect that if that were not in the context of the prompt that the proposed change might have missed using source_file/2.

In other words, years of experience with SWI-Prolog is what enables the created plans to be effective, I assure you many plans need adjustments and sometimes are just tossed after four attempts to get them headed in the right direction.

EricGT · December 11, 2025, 10:14pm

The following is a Claude generated plan. Plans are created using markdown and the exact file contents of the plan are pasted below, no changes needed since Discourse can display the markdown.

The plan was created in VScode with Claude Code for VS Code
Model: Opus 4.5
Plan mode: active
Thinking: On

In my workflow after the changes are working as expected, including changes needed that were not in the plan, I run a skill that checks my current local skills and if anything was learned that may be of value as a new skill or addition to existing skills will create a plan to add/update the local skills.

Thus Claude learns new skills from my mistakes, fixing overlooked details, etc.

Plan: Add Directive Filtering to prolog_coverage_ai

Summary of Changes

File	Change
`lib/prolog_coverage_ai.pl`	Rename module, add `skip_directive_clauses/1` option, modify `line_annotation`
`scripts/run_coverage_tests.pl`	Import local module, use new option

Goal

Create a local copy of prolog_coverage.pl renamed as prolog_coverage_ai module, with a new option to filter out ### (uncovered) annotations for persistent/1 directives.

Problem Analysis

The persistent/1 directive uses term expansion to generate multiple predicates at compile time. The coverage system sees:

The directive itself - marked as ### (never “executed” at runtime)
The generated predicates - these ARE executed and show ++N counts

The ### is misleading since directives aren’t runtime-executed code.

Call Chain for `###` Annotations

show_coverage/1 (line 280)
  └─ file_coverage/3 (line 313)
       └─ file_details/4 (line 427)
            └─ detailed_report/4 (line 723)
                 └─ line_annotation/4 (line 745) ← Creates ### annotation

Key code at line 745-748:

line_annotation(File, uncovered, Clause, Annotation) :-
    !,
    clause_or_set_source_location(Clause, File, Line),
    Annotation = (Line-ansi(error,###))-3.

Implementation Plan

Step 1: Rename Module

Change module declaration from prolog_coverage to prolog_coverage_ai
File: lib/prolog_coverage_ai.pl

Step 2: Add New Option

Add option skip_directive_clauses(+Predicates) where Predicates is a list like [persistent/1].

2a. Update predicate_options declaration (~line 138):

:- predicate_options(show_coverage/1, 1,
                     [ ...existing options...,
                       skip_directive_clauses(list)  % NEW
                     ]).

2b. Update module documentation (~line 256, after the annotation table):
Add to the show_coverage/1 documentation:

%     - skip_directive_clauses(+Directives)
%       A list of Directive/Arity terms. Clauses whose source line
%       contains a matching directive (e.g., `:- persistent(...)`) will
%       not be marked with `###` even if uncovered. This is useful for
%       term-expanding directives like persistent/1 where the directive
%       itself is not runtime code but generates runtime predicates.
%       Example: `skip_directive_clauses([persistent/1])`

Step 3: Modify line_annotation/4 (line 745)

Add a clause that checks if we should skip this uncovered clause:

line_annotation(File, uncovered, Clause, Annotation, Options) :-
    option(skip_directive_clauses(Directives), Options, []),
    Directives \== [],
    clause_is_directive(Clause, File, Directives),
    !,
    fail.  % Skip this clause - no annotation generated
line_annotation(File, uncovered, Clause, Annotation, _Options) :-
    !,
    clause_or_set_source_location(Clause, File, Line),
    Annotation = (Line-ansi(error,###))-3.

Step 4: Add Helper Predicate clause_is_from_directive/3

%% clause_is_from_directive(+Clause, +File, +Directives) is semidet.
%  True if Clause's source line matches a directive pattern.
%  Directives is a list like [persistent/1, discontiguous/1].
clause_is_from_directive(Clause, File, Directives) :-
    clause_or_set_source_location(Clause, File, Line),
    catch(file_line_text(File, Line, LineText), _, fail),
    member(Directive/_Arity, Directives),
    format(atom(Pattern), ':- ~w(', [Directive]),
    sub_atom(LineText, _, _, _, Pattern).

%% file_line_text(+File, +LineNo, -Text) is det.
%  Read specific line from file. Uses file_text/2 already in module.
file_line_text(File, LineNo, Text) :-
    file_text(File, String),
    split_string(String, "\n", "", Lines),
    nth1(LineNo, Lines, Text).

Note: The file_text/2 predicate already exists in the module (line 888) for reading file content.

Step 5: Thread Options Through Call Chain

Predicates needing modification to pass Options:

detailed_report/4 (line 723) - already has Options, passes to line_annotation
line_annotation/4 (line 745) - change to line_annotation/5 with Options param

The convlist/3 calls at lines 726-727 need updating:

% Before:
convlist(line_annotation(File, uncovered), Uncovered, Annot1),

% After:
convlist(line_annotation(File, uncovered, Options), Uncovered, Annot1),

Note: convlist/3 uses a goal with arity N, calling it with N+2 args. So line_annotation/5 works as line_annotation(File, uncovered, Options) + 2 args from convlist = 5 args total.

Step 6: Update run_coverage_tests.pl

Change import and add new option:

:- use_module('lib/prolog_coverage_ai').

% In show_coverage_safe/1:
show_coverage([color(false), skip_directive_clauses([persistent/1]) | Options])

Files to Modify

lib/prolog_coverage_ai.pl - Main changes (rename + new filtering)
scripts/run_coverage_tests.pl - Use local module with new option

Testing

Run: swipl scripts/run_coverage_tests.pl 2>&1 | tee coverage_test_results.log
Verify: cov/introspection_engine.pl.cov no longer shows ### for persistent/1 lines

Here is an example of things I missed in the plan or just in situational awareness

Noting that the test take 10 minutes to run, so in inspecting the command added as a reply.

Forgot to check my token usage which ran out in the middle of running the tests. Normally I will not reply which leaves the process ready to go once the limit resets. Resuming a session for token limit reached can sometimes use 5% of all tokens, ouch.

Should have noted in the plan that I would manually run the test and check the results. Doing so stops the AI from wasting tokens in a loop checking for the test to end.
Should have switched the LMM model from Opus 4.5 to the cheaper model Sonnet 4.5 which is easily capable of doing the code changes and using a lot less tokens and turning thinking off.

In checking the cov file to verify that the ### are filtered out for persistent/1 directives

   90 ++20 ⮰
      ++4,727 ⮰
      ++21,486 ⮰
      +55,950-20             :- persistent(pred_def(name:atom, arity:integer, module:atom, file:atom, line:integer)).

the code works as expected.

However since my knowledge of all of the places where this specific case would be of use more generally, or adjusted as needed, I do not plan to submit a PR.

Also since there is nothing that would be new as a Claude skill will skip running the check for possible skills.

prolog_coverage_ai.pl (45.8 KB)

EricGT · December 12, 2025, 2:21am

So by chance had the OUTPUT tab open instead of the TERMINAL tab in VS Code so decided to read the messages while Claude was working. Spotted LSP in the stream right after an SWI-Prolog *.pl file was listed.

2025-12-11 20:11:46.495 [info] [DiagnosticTracking] No new diagnostics found for c:\Users\Eric\Projects\Prolog_AI_Assistant_Research\lib\prolog_coverage_ai.pl
2025-12-11 20:11:46.635 [info] From claude: 2025-12-12T02:11:46.633Z [DEBUG] LSP Diagnostics: getLSPDiagnosticAttachments called
2025-12-12T02:11:46.633Z [DEBUG] LSP Diagnostics: Checking registry - 0 pending
2025-12-12T02:11:46.634Z [DEBUG] Hooks: Found 0 total hooks in registry
2025-12-12T02:11:46.634Z [DEBUG] Hooks: checkForNewResponses returning 0 responses

Looking at the entire OUTPUT found

2025-12-11 15:26:17.497 [info] From claude: 2025-12-11T21:26:17.498Z [DEBUG] Total LSP servers loaded: 0

Asked Claude to create the following markdown document (which has not been verified). This sheds more light with details on my earlier reply.

Claude Code LSP Integration Guide

Last Updated: 2025-12-12
Audience: Beginners to Prolog, LSP, and Claude Code
Purpose: Understanding if and how Claude Code can integrate with Language Server Protocol (LSP) for SWI-Prolog development

What is LSP?

Language Server Protocol (LSP) is a standardized protocol that allows code editors (like VS Code) to communicate with language-specific tools that provide:

Error checking (syntax errors, type errors)
Autocomplete (intelligent code suggestions)
Go to definition (jump to where functions/predicates are defined)
Find references (see where code is used)
Hover information (documentation popups)
Linting warnings (code quality suggestions)

Why LSP Matters

Before LSP, every editor needed custom support for each programming language. LSP standardizes this:

Editor (VS Code) <--> LSP Protocol <--> Language Server (Prolog LSP)

This means one Prolog language server can work with any LSP-compatible editor.

LSP Diagnostics

Diagnostics are error messages, warnings, and hints about your code that the language server sends to your editor. When you see red squiggles under code with error messages, that’s LSP diagnostics in action.

What is Claude Code?

Claude Code is an AI-powered coding assistant that can:

Read and analyze your codebase
Write and edit code
Debug problems
Answer questions about your code
Run tests and build commands

Claude Code Variants

CLI Tool - Command-line interface for terminal use
VS Code Extension - Integrated into Visual Studio Code
JetBrains Plugin - For IntelliJ, PyCharm, etc.

How Claude Code Uses LSP

Claude Code can integrate with LSP diagnostics to:

See errors and warnings in your code automatically
Understand what’s broken before you explain it
Provide more accurate fixes
Include diagnostic context in AI conversations

Understanding the Log Messages

When using Claude Code for VS Code, you may see messages like this in the OUTPUT tab:

2025-12-11 20:11:46.635 [info] From claude: 2025-12-12T02:11:46.633Z [DEBUG] LSP Diagnostics: getLSPDiagnosticAttachments called
2025-12-11 20:11:46.635 [info] From claude: 2025-12-12T02:11:46.633Z [DEBUG] LSP Diagnostics: Checking registry - 0 pending
2025-12-11 20:11:46.635 [info] From claude: 2025-12-12T02:11:46.634Z [DEBUG] Hooks: Found 0 total hooks in registry
2025-12-11 15:26:17.497 [info] From claude: 2025-12-11T21:26:17.498Z [DEBUG] Total LSP servers loaded: 0

Message Breakdown

Message Structure

2025-12-11 20:11:46.635 [info] From claude: 2025-12-12T02:11:46.633Z [DEBUG] LSP Diagnostics: getLSPDiagnosticAttachments called
│                      │        │                           │                │                                              │
│                      │        │                           │                │                                              └─ Debug message
│                      │        │                           │                └─ Claude Code's internal log level
│                      │        │                           └─ Claude Code's timestamp (UTC)
│                      │        └─ Message source identifier
│                      └─ VS Code's log level
└─ VS Code's timestamp (local time)

Key Components

Component	Meaning
`[info] From claude:`	Message originated from Claude Code extension
`[DEBUG]`	Internal debug-level logging from Claude Code
`getLSPDiagnosticAttachments called`	Claude Code is checking for LSP diagnostics to include in AI context
`Checking registry - 0 pending`	No diagnostics found in the internal registry
`Total LSP servers loaded: 0`	No LSP servers are currently connected to Claude Code

What Does “getLSPDiagnosticAttachments” Mean?

This is an internal function that:

Runs when: Claude Code prepares to send a message to the AI
Purpose: Gather any LSP diagnostics (errors/warnings) from your code
Action: Packages diagnostics as “attachments” to include in the conversation
Result: Returns empty if no diagnostics found

Flow:

User sends message to Claude
    ↓
Claude Code prepares AI request
    ↓
getLSPDiagnosticAttachments() called
    ↓
Checks LSP diagnostic registry
    ↓
Finds: "0 pending" (no errors/warnings)
    ↓
Message sent to AI without diagnostic context

Why “0 LSP servers loaded”?

This message indicates no LSP servers are connected to Claude Code. This means:

Claude Code’s LSP integration system is running
No language servers are connected to it
Claude Code cannot see LSP diagnostics from your editor

This is a configuration gap, not a fundamental limitation.

Can Claude Code Integrate with LSP?

Short Answer

Yes, but with limitations and workarounds needed.

Detailed Answer

Built-in Support

Claude Code version 2.0.30+ (October 31, 2024) includes:

Basic LSP support system
Automatic diagnostic sharing in VS Code extension
$ENABLE_LSP_TOOL=1 environment variable to enable LSP tool
Still early/raw - bugs exist, limited documentation

Current Limitations (as of 2025-12-12)

VS Code Extension Paradox
- CLI version has better IDE integration than the native VS Code extension
- VS Code extension missing the mcp__ide__getDiagnostics MCP tool
- Source: Issue #8635
No UI Indication
- No visual feedback when LSP servers start/stop
- No indication of errors in LSP server connections
- Debug logs are the only way to see status
Limited Documentation
- Official docs don’t detail LSP setup
- Community-driven workarounds needed

Two Integration Levels

Level 1: VS Code Native LSP (Working)

Your Code <--> Prolog LSP Server <--> VS Code
                                        │
                                        └─> Shows errors in Problems panel

VS Code itself can use Prolog LSP servers to show you errors, regardless of Claude Code.

Level 2: Claude Code Access to LSP (Needs Configuration)

Your Code <--> Prolog LSP Server <--> VS Code <--> Claude Code Extension
                                                        │
                                                        └─> Claude sees diagnostics

This requires additional setup using MCP servers or waiting for improved built-in support.

SWI-Prolog LSP Implementations

Overview

There are two main LSP server implementations for SWI-Prolog:

Implementation	Maturity	Recommended	Platform Support
lsp_server by jamesnvc	Mature	Yes	Linux, macOS, Windows (with caveats)
prolog_lsp by hargettp	Experimental	No	All platforms (but immature)

Option 1: lsp_server (Recommended)

Repository: GitHub - jamesnvc/lsp_server: Language Server Protocol server for SWI-Prolog
SWI-Prolog Pack: "lsp_server" pack for SWI-Prolog
Maturity: Production-ready

Features

Find definitions
Find references
Hover documentation
Code completion
Diagnostics (errors/warnings)
Signature help

Installation

Method 1: Using pack_install

?- pack_install(lsp_server).

Method 2: Using swipl command

swipl pack install lsp_server

Requirements

SWI-Prolog 8.1.5 or newer (for best results with “find references”)
Requires xref_called/5 predicate (available in 8.1.5+)

Windows-Specific Configuration

IMPORTANT: On Windows (not WSL), running the server via stdio will NOT work.

Solution: Run the server over a socket instead:

# Start lsp_server on a specific port
swipl -g "lsp_server:main([port, 5007])" -t halt

As of version 2.5.0, socket mode is supported via command-line arguments:

port <port_number>

instead of stdio.

VS Code Extension: swi-lsp

Marketplace: swi-lsp - Visual Studio Marketplace

This extension provides VS Code integration for lsp_server.

Installation:

Open VS Code
Go to Extensions (Ctrl+Shift+X)
Search for “swi-lsp”
Click Install

Configuration: See the extension’s README for connecting to the LSP server.

Option 2: prolog_lsp (Experimental)

Repository: GitHub - hargettp/prolog_lsp: Language Server for Prolog
SWI-Prolog Pack: "prolog_lsp" pack for SWI-Prolog
Maturity: Experimental (not recommended for production)

Status

From the author:

“This project is very immature and not at all recommended for daily production use.”

When to Consider

You want to contribute to LSP development
You’re experimenting with alternative implementations
You need features not yet in lsp_server

MCP Server Options for Enhanced Integration

Model Context Protocol (MCP) servers can bridge the gap between Claude Code and LSP diagnostics.

What is MCP?

MCP is a protocol that allows AI assistants like Claude to access external tools and data sources. MCP servers act as middleware that:

Connect Claude Code to LSP servers
Expose LSP features as tools Claude can use
Work around limitations in Claude Code’s built-in LSP support

Available MCP Servers for LSP Integration

1. cclsp (Claude Code LSP)

Repository: GitHub - ktnyt/cclsp: Claude Code LSP: enhance your Claude Code experience with non-IDE dependent LSP integration.
MCP Market: https://mcpmarket.com/server/cclsp

Features

Pull current diagnostics using textDocument/diagnostic
Find definitions, references, rename symbols
Server restart capabilities
Intelligent position handling (tries multiple combinations)
Robust symbol resolution

Why It Helps

Solves the common problem where AI agents struggle with accurate line/column numbers when communicating with LSP servers.

Use Case

You want Claude Code to have direct access to LSP features regardless of IDE limitations.

2. tritlo/lsp-mcp

Playbooks: LSP MCP server for AI agents

Features

Hover information
Code completions
Diagnostics
Generic LSP feature access for LLMs

Why It Helps

Provides a clean interface for AI agents to query LSP servers for any language.

Use Case

You want a language-agnostic MCP server that works with multiple LSP servers.

3. @juanpprieto/claude-lsp

NPM Package: https://www.npmjs.com/package/@juanpprieto/claude-lsp

Features

Hook-based diagnostic injection
Real-time code analysis
TypeScript LSP integration
ESLint checking
Prettier formatting
GraphQL checks

Why It Helps

Automatically injects diagnostics into Claude’s context using hooks, so Claude sees:

Type errors
Lint warnings
Formatting issues

Use Case

You want automatic, real-time diagnostic sharing without manual intervention.

Comparison of MCP Servers

Feature	cclsp	tritlo/lsp-mcp	@juanpprieto/claude-lsp
Diagnostics
Definitions
References
Hover Info
Completions
Auto-injection			(via hooks)
Multi-language			(JS/TS focused)
Position handling	(robust)
Server restart
Prolog support	(any LSP)	(any LSP)	(JS/TS focused)

Legend:

= Supported
= Not supported
= Unknown/unclear
= Partial support

Comparison of LSP Integration Approaches

Overview Table

Approach	Setup Complexity	Claude Access	Cost	Maturity	Platform Support
VS Code Native Only	Low	None	Free	Mature	All
Built-in Claude Code LSP	Low-Medium	Limited	Free	Early/Raw	All
MCP Server (cclsp)	Medium	Full	Free	Moderate	All
MCP Server (tritlo)	Medium	Full	Free	Moderate	All
MCP Server (@juanpprieto)	Medium-High	Auto	Free	Moderate	All

Detailed Comparison

1. VS Code Native LSP Only

Setup:

Install Prolog LSP extension (swi-lsp) → Configure → Done

Pros:

Simple setup
Works independently of Claude Code
Well-documented
Stable

Cons:

Claude Code cannot see diagnostics
No AI-assisted error fixing
Manual error explanation needed

Best For: Users who want VS Code LSP features but don’t need Claude to access diagnostics.

2. Built-in Claude Code LSP Support

Setup:

export ENABLE_LSP_TOOL=1
# Or set in VS Code settings

Pros:

No additional software needed
Official support from Anthropic
Automatic diagnostic sharing (in theory)

Cons:

Early/raw implementation (as of 2025-12)
Bugs in different LSP operations
No documentation
No UI indication of status
VS Code extension missing MCP tool

Best For: Early adopters willing to work through limitations while the feature matures.

3. MCP Server Integration (cclsp)

Setup:

# Install cclsp MCP server
npm install -g cclsp

# Configure in Claude Code settings
# Point to your Prolog LSP server

Pros:

Full LSP feature access
Robust position handling
Works around IDE limitations
Server restart capabilities
Language-agnostic

Cons:

Additional software to install
More complex configuration
Requires understanding of MCP

Best For: Power users who want complete LSP integration and are comfortable with configuration.

4. MCP Server Integration (tritlo/lsp-mcp)

Setup:

# Install and configure tritlo/lsp-mcp
# Connect to Prolog LSP server

Pros:

Generic LSP interface
Multi-language support
Hover, completions, diagnostics

Cons:

Additional software to install
Configuration complexity
Less documentation than cclsp

Best For: Users working with multiple languages who want one MCP server for all LSP interactions.

5. Hook-based Auto-injection (@juanpprieto/claude-lsp)

Setup:

npm install @juanpprieto/claude-lsp

# Configure hooks in Claude Code
# Set up automatic injection

Pros:

Automatic diagnostic injection
Real-time analysis
No manual triggering needed
Hook-based workflow integration

Cons:

Most complex setup
Primarily JS/TS focused (Prolog support unclear)
Requires hook configuration knowledge

Best For: TypeScript/JavaScript developers who want fully automatic diagnostic sharing; Prolog support uncertain.

Decision Matrix

Choose VS Code Native Only if:

You only need LSP features in your editor
You don’t need Claude to see diagnostics
You want the simplest setup

Choose Built-in Claude Code LSP if:

You’re okay with early-stage software
You want official support
You can wait for maturity improvements

Choose cclsp MCP Server if:

You need full LSP feature access in Claude
You want robust, reliable integration
You’re comfortable with configuration

Choose tritlo/lsp-mcp if:

You work with multiple languages
You want a generic LSP solution
You prefer flexibility over specialization

Choose @juanpprieto/claude-lsp if:

You primarily work with TypeScript/JavaScript
You want automatic diagnostic injection
You’re willing to invest in complex setup

Claude Code for VS Code: Known Issues

This section documents specific issues when using Claude Code through the VS Code chat interface.

Issue 1: Missing MCP IDE Diagnostics Tool

Reference: Issue #8635

Problem:

CLI version of Claude Code has mcp__ide__getDiagnostics tool
VS Code extension is missing this tool
Paradox: External CLI has better IDE access than native extension

Impact:

VS Code extension cannot retrieve Pylance/LSP diagnostics via MCP
Reduces effectiveness compared to CLI version
“Fix with Claude Code” feature may not work properly

Status: Open issue (as of 2025-12-12)

Workaround:

Use CLI version with --ide flag to connect to VS Code
Use MCP servers (cclsp, tritlo/lsp-mcp) to bridge the gap
Wait for official fix

Issue 2: LSP Integration Worse Than CLI

Reference: Issue #8635 (same issue)

Problem:

“The CLI version of Claude Code can connect to IDEs and access diagnostics. But the VSCode Extension (which runs inside the IDE) has worse IDE integration.”

Expected Behavior:

VS Code extension should have better LSP access
Should see all diagnostics automatically
Should integrate seamlessly with native LSP features

Actual Behavior:

Extension shows “Total LSP servers loaded: 0”
Cannot access diagnostics that VS Code itself can see
Requires workarounds to access native IDE features

Issue 3: “Fix with Claude Code” Action Broken

Reference: Issue #2269

Problem:

“Fix with Claude Code” action in VS Code doesn’t work properly
Diagnostic information not passed correctly to Claude
May fail silently or provide incomplete context

Impact:

Quick-fix workflow broken
Must manually describe errors to Claude
Reduces productivity

Workaround:

Manually copy error messages to Claude chat
Use terminal/CLI commands to run diagnostics
Wait for official fix

Issue 4: No UI Indication of LSP Server Status

Problem:

No visual feedback in VS Code about LSP server connections
No way to know if LSP integration is working
Must check OUTPUT tab logs to debug

Impact:

Users unaware of connection issues
Difficult to troubleshoot
“0 LSP servers loaded” discovered only through logs

Workaround:

Regularly check OUTPUT tab → Select “Claude Code” source
Look for debug messages about LSP servers
Monitor for “Total LSP servers loaded: X” messages

Issue 5: Early/Raw LSP Support

Reference: Issue #5495 discussion

Problem:

LSP support added in v2.0.30 but still immature
Bugs in different LSP operations
Missing documentation
No standardized configuration

Known Bugs:

Socket vs stdio connection issues
Server initialization failures
Position/offset calculation errors
Timeout issues (especially in JetBrains IDEs)

Workaround:

Use $ENABLE_LSP_TOOL=1 environment variable
Report bugs to GitHub issues
Use MCP servers for more stable integration
Contribute to community testing

Issue 6: Windows-Specific Problems

Problem:

Prolog LSP server (lsp_server) doesn’t support stdio on Windows
Must use socket mode instead
Configuration more complex than Linux/macOS

Impact:

Windows users need extra configuration steps
May encounter connection errors with default settings

Solution:

Always use socket mode on Windows:

swipl -g "lsp_server:main([port, 5007])" -t halt

Configure VS Code extension to connect via socket
See lsp_server documentation

Known Workarounds Summary

Issue	Workaround	Effort	Effectiveness
Missing MCP tool	Use CLI with `--ide` flag	Medium	Good
Missing MCP tool	Use cclsp/tritlo MCP server	Medium-High	Excellent
Poor LSP integration	Use MCP servers	Medium-High	Excellent
“Fix with Claude” broken	Manual error copying	Low	Partial
No UI indication	Monitor OUTPUT logs	Low	Diagnostic only
Windows stdio issues	Use socket mode	Medium	Good

Troubleshooting

Problem: “Total LSP servers loaded: 0”

Symptoms:

[DEBUG] Total LSP servers loaded: 0
[DEBUG] LSP Diagnostics: Checking registry - 0 pending

Causes:

No Prolog LSP server installed in VS Code
LSP server installed but not connected to Claude Code
Claude Code’s LSP integration not enabled

Solutions:

Step 1: Install Prolog LSP Server

# Install lsp_server pack
swipl -g "pack_install(lsp_server)" -t halt

# Or install VS Code extension
# Search "swi-lsp" in VS Code Extensions marketplace

Step 2: Enable Claude Code LSP Support

# Set environment variable
export ENABLE_LSP_TOOL=1

# Or in VS Code settings.json
{
  "claude-code.enableLSP": true
}

Step 3: Verify LSP Server Running

Open a Prolog file in VS Code
Check Problems panel (Ctrl+Shift+M) for diagnostics
If VS Code shows diagnostics, LSP server is working

Step 4: Install MCP Server (Alternative)

# Install cclsp
npm install -g cclsp

# Configure in Claude Code MCP settings

Problem: No Diagnostics Showing in VS Code

Symptoms:

No errors/warnings in Problems panel
Red squiggles not appearing under code
LSP server seems not to work

Solutions:

Check 1: Is the LSP Extension Installed?

Go to Extensions (Ctrl+Shift+X)
Search “swi-lsp” or “prolog”
Install if missing

Check 2: Is the LSP Server Running?

On Linux/macOS:

ps aux | grep lsp_server

On Windows:

Get-Process | Select-String "swipl"

Check 3: VS Code Output Logs

Open OUTPUT tab (Ctrl+Shift+U)
Select “SWI-Prolog Language Server” from dropdown
Look for error messages

Check 4: Restart LSP Server

Open VS Code Command Palette (Ctrl+Shift+P)
Type “Reload Window”
Or restart VS Code entirely

Problem: Windows Socket Connection Errors

Symptoms:

LSP server fails to start
“Connection refused” errors
stdio-related errors

Solution:

Must use socket mode on Windows:

# Start LSP server on specific port
swipl -g "lsp_server:main([port, 5007])" -t halt

Configure VS Code extension (settings.json):

{
  "swi-lsp.server.host": "localhost",
  "swi-lsp.server.port": 5007
}

Problem: Claude Code Can’t See Diagnostics VS Code Shows

Symptoms:

VS Code Problems panel shows errors
Claude Code shows “0 pending” diagnostics
LSP server working but Claude can’t access it

Root Cause:

VS Code extension missing mcp__ide__getDiagnostics tool
Claude Code’s LSP integration not connected to VS Code’s LSP

Solutions:

Option 1: Use MCP Server

npm install -g cclsp
# Configure to connect to your Prolog LSP server

Option 2: Use CLI with IDE Connection

claude --ide vscode

Option 3: Wait for Official Fix

Track Issue #8635
Update to latest Claude Code version when fixed

Problem: “Fix with Claude Code” Does Nothing

Symptoms:

Right-click on error → “Fix with Claude Code”
Nothing happens or error appears
Diagnostic not passed to Claude

Solution:

Manual Workaround:

Copy the error message from Problems panel
Open Claude Code chat
Paste error and ask for fix
Apply fix manually

Permanent Solution:

Wait for Issue #2269 fix
Use MCP server integration instead

Resources

Appendix: Example VS Code Configuration

settings.json for SWI-Prolog LSP

{
  // SWI-Prolog LSP Server Configuration
  "swi-lsp.server.enabled": true,
  "swi-lsp.server.host": "localhost",
  "swi-lsp.server.port": 5007,

  // Claude Code Configuration
  "claude-code.enableLSP": true,
  "claude-code.debug": true,

  // Prolog File Associations
  "files.associations": {
    "*.pl": "prolog",
    "*.pro": "prolog"
  }
}

Environment Variables

# Enable Claude Code LSP tool
export ENABLE_LSP_TOOL=1

# Enable debug logging
export CLAUDE_CODE_DEBUG=1

Appendix: Starting LSP Server Manually

Linux/macOS

#!/bin/bash
# start-prolog-lsp.sh

# Start lsp_server in stdio mode
swipl -g "lsp_server:main([stdio])" -t halt

Windows (Socket Mode Required)

# start-prolog-lsp.ps1

# Start lsp_server in socket mode
& "C:\Program Files\swipl\bin\swipl.exe" -g "lsp_server:main([port, 5007])" -t halt

Summary

Key Takeaways

LSP is a protocol that connects editors to language-specific tools for error checking, autocomplete, and more.
Claude Code can integrate with LSP, but support is early/raw as of 2025-12-12.
“Total LSP servers loaded: 0” means no LSP servers are connected to Claude Code - this is a configuration issue, not a limitation.
For SWI-Prolog, use lsp_server by jamesnvc (mature) or the swi-lsp VS Code extension.
Windows users must use socket mode - stdio doesn’t work for lsp_server on Windows.
VS Code extension has limitations - missing MCP tool, worse than CLI version.
MCP servers (cclsp, tritlo/lsp-mcp) provide workarounds for Claude Code’s LSP integration gaps.
Multiple integration approaches exist - choose based on complexity tolerance and feature needs.

Quick Start Checklist

Install SWI-Prolog (if not already installed)
Install lsp_server pack: ?- pack_install(lsp_server).
Install swi-lsp VS Code extension
Configure socket mode (Windows) or stdio mode (Linux/macOS)
Verify LSP works in VS Code (check Problems panel)
Choose Claude Code integration approach:
- Built-in (simple, limited)
- MCP server (complex, full-featured)
Enable ENABLE_LSP_TOOL=1 if using built-in
Test: Open Prolog file with errors, check if Claude sees them

bauhaus911 · December 14, 2025, 10:07pm

Here is my experience creating a python app that communicated with a SWI-Prolog database that used a local (running on my game gpu) llm via ollama to make queries on my Prolog knowledge base. I’m a retired s/w dev but have only a beginner level of experience in Python and zero expertise with Prolog. Claude Code wrote it all for me (Sonnet 4.x). This was pre-skills.

I need to circle back around and see where skills might fit in (and plans).

abaljeu · December 15, 2025, 2:20pm

I hadn’t read about Claude Skills before, so thanks for the tip. I use Claude Code often. I deliberately don’t use Plan Mode. I’ve found it just makes things harder, and the easier way is to ask Claude to write a plan while in Agent mode. Then I just get a text file, and I can more easily review and edit the plan.

EricGT · December 15, 2025, 9:48pm

Seems that OpenAI may be implementing Plans and skills for Codex.

github.com/openai/codex

docs/skills.md

2c6995ca4

# Skills (experimental)

> **Warning:** This is an experimental and non-stable feature. If you depend on it, please expect breaking changes over the coming weeks and understand that there is currently no guarantee that this works well. Use at your own risk!

Codex can automatically discover reusable "skills" you keep on disk. A skill is a small bundle with a name, a short description (what it does and when to use it), and an optional body of instructions you can open when needed. Codex injects only the name, description, and file path into the runtime context; the body stays on disk.

## Enable skills

Skills are behind the experimental `skills` feature flag and are disabled by default.

- Enable in config (preferred): add the following to `$CODEX_HOME/config.toml` (usually `~/.codex/config.toml`) and restart Codex:

  ```toml
  [features]
  skills = true
  ```

- Enable for a single run: launch Codex with `codex --enable skills`

## Where skills live

This file has been truncated. show original

EricGT · December 15, 2025, 9:56pm

FYI - Plan mode will create a markdown file in ~/.claude/plans. It creates a new name of three words not related to the plan and will reuse/overwrite the plan if a new plan is created in the same conversation. However if you check for the latest timestamp of file in the directory right after you create a plan, you can look at it, e.g. in VS Code with a markdown extension that has a preview mode.

I often copy the plan files into a coding project as part of a Git feature branch.

EricGT · December 20, 2025, 8:07pm

The latest Claude Code update adds some LSP changes

Added LSP (Language Server Protocol) tool for code intelligence features like go-to-definition, find references, and hover documentation

EricGT · December 22, 2025, 3:53pm

The official pages for Skills from Anthropic and OpenAI and the open standard.

Topic		Replies	Views
Using code to develop prolog programs General	12	216	August 29, 2024
IDE/Editor for SWI-Prolog? Tools	38	21420	August 23, 2019
ChatGPT SWI-Prolog assistent Nice to know chatgpt , llm	27	600	July 1, 2025
Prolog LSP now supports colours (Discussion) Discussion	27	1386	April 22, 2025
New: Connect AI Assistants Directly to SWI-Prolog Nice to know	3	121	September 3, 2025

Plan: Add Directive Filtering to prolog_coverage_ai

Summary of Changes

Goal

Problem Analysis

Call Chain for ### Annotations

Implementation Plan

Step 1: Rename Module

Step 2: Add New Option

Step 3: Modify line_annotation/4 (line 745)

Step 4: Add Helper Predicate clause_is_from_directive/3

Step 5: Thread Options Through Call Chain

Step 6: Update run_coverage_tests.pl

Files to Modify

Testing

Claude Code LSP Integration Guide

Table of Contents

What is LSP?

Why LSP Matters

LSP Diagnostics

What is Claude Code?

Claude Code Variants

How Claude Code Uses LSP

Understanding the Log Messages

Message Breakdown

Message Structure

Key Components

What Does “getLSPDiagnosticAttachments” Mean?

Why “0 LSP servers loaded”?

Can Claude Code Integrate with LSP?

Short Answer

Detailed Answer

Built-in Support

Current Limitations (as of 2025-12-12)

Two Integration Levels

Level 1: VS Code Native LSP (Working)

Level 2: Claude Code Access to LSP (Needs Configuration)

SWI-Prolog LSP Implementations

Overview

Option 1: lsp_server (Recommended)

Features

Installation

Requirements

Windows-Specific Configuration

VS Code Extension: swi-lsp

Option 2: prolog_lsp (Experimental)

Status

When to Consider

MCP Server Options for Enhanced Integration

What is MCP?

Available MCP Servers for LSP Integration

1. cclsp (Claude Code LSP)

Features

Why It Helps

Use Case

2. tritlo/lsp-mcp

Features

Why It Helps

Use Case

3. @juanpprieto/claude-lsp

Features

Why It Helps

Use Case

Comparison of MCP Servers

Comparison of LSP Integration Approaches

Overview Table

Detailed Comparison

1. VS Code Native LSP Only

2. Built-in Claude Code LSP Support

3. MCP Server Integration (cclsp)

4. MCP Server Integration (tritlo/lsp-mcp)

5. Hook-based Auto-injection (@juanpprieto/claude-lsp)

Decision Matrix

Claude Code for VS Code: Known Issues

Issue 1: Missing MCP IDE Diagnostics Tool

Issue 2: LSP Integration Worse Than CLI

Issue 3: “Fix with Claude Code” Action Broken

Issue 4: No UI Indication of LSP Server Status

Issue 5: Early/Raw LSP Support

Issue 6: Windows-Specific Problems

Known Workarounds Summary

Call Chain for `###` Annotations