¿Alguna vez viste a GitHub Copilot CLI extraer un archivo JAR a un directorio temporal, hacer grep sobre archivos .class y reconstruir la firma de una API a partir de bytecode crudo? El agente es ingenioso, pero sin un language server eso es lo mejor que puede hacer.

El Language Server Protocol (LSP) es el estándar que da poder a go-to-definition, find references y resolución de tipos en editores como VS Code. Funciona igual de bien en la terminal. El skill LSP Setup automatiza la instalación y configuración de servidores LSP para Copilot CLI, así el agente obtiene respuestas precisas y estructuradas sobre el código en vez de depender de heurísticas de búsqueda de texto.

¿Qué problema resuelve el LSP en un agente de terminal?

Sin un servidor LSP, el agente de Copilot CLI ingeniería en reversa la información de la API mediante búsqueda de texto y extracción binaria. Para un proyecto Java, eso se ve así:

Bash
# Buscar el JAR de la dependencia
find ~/.m2/repository -name "*httpclient*.jar"

# Extraerlo a un directorio temporal
mkdir /tmp/httpclient && cd /tmp/httpclient
jar xf ~/.m2/repository/org/apache/httpcomponents/httpclient/4.5.14/httpclient-4.5.14.jar

# Buscar la firma de un método sobre los .class extraídos
grep -r "execute" --include="*.class" .

Para Python, el agente hace cat sobre archivos dentro de site-packages. Para TypeScript, recorre node_modules. Estas estrategias basadas en texto funcionan para casos simples, pero hacen pattern matching sobre texto crudo en vez de análisis semántico real: se pierden los genéricos, los overloads y los tipos transitivos, y no pueden ver bytecode compilado. Ese es exactamente el hueco que cubre un language server.

Un servidor LSP lo resuelve estructuralmente. Cuando el agente envía una request textDocument/definition para un símbolo, el language server devuelve la ubicación exacta del fuente, el tipo totalmente resuelto y la firma.

¿Cómo funciona el skill LSP Setup?

Al gatillarse, el skill ejecuta un flujo de siete pasos:

1. Selección de lenguaje: el agente usa ask_user con un set de opciones para determinar qué lenguaje necesita soporte LSP. 2. Detección del sistema operativo: el agente corre uname -s (o revisa $env:OS en Windows) porque los comandos de instalación cambian. Por ejemplo, brew install jdtls en macOS versus descarga desde eclipse.org en Linux. 3. Lookup del servidor LSP: el skill incluye un archivo de referencia (references/lsp-servers.md) con datos curados para 14 lenguajes: comandos de instalación por sistema operativo, nombres de binarios y snippets de config listos para usar. 4. Scope de la configuración: el agente pregunta si la config debe ser a nivel usuario (~/.copilot/lsp-config.json, aplica a todos los repos) o a nivel repo (lsp.json en la raíz o .github/lsp.json, scoped a un proyecto). La config a nivel repo tiene precedencia. 5. Instalación: el agente corre el comando apropiado. Por ejemplo:

Bash
# TypeScript en cualquier OS
npm install -g typescript typescript-language-server

# Java en macOS
brew install jdtls

# Rust en cualquier OS
rustup component add rust-analyzer

6. Configuración: el agente escribe o fusiona una entrada en el archivo de config elegido. El formato usa un objeto lspServers donde cada clave es un identificador de servidor:

JSON
{
  "lspServers": {
    "java": {
      "command": "jdtls",
      "args": [],
      "fileExtensions": {
        ".java": "java"
      }
    }
  }
}

Reglas que el skill aplica: command debe estar en $PATH o ser ruta absoluta, args suele incluir "--stdio" para transporte por I/O estándar (algunos servidores como jdtls lo manejan internamente), fileExtensions mapea cada extensión a un identificador de lenguaje, y las entradas existentes se preservan: el agente fusiona, nunca sobrescribe.

7. Verificación: el agente corre which <binary> (o where.exe en Windows) para confirmar que el servidor está accesible, luego valida que el archivo de config sea JSON bien formado.

¿Qué cambia después del setup?

Con el LSP configurado, el agente de la CLI puede:

  • Resolver tipos a través de dependencias: se acabó el grep sobre JARs y node_modules.
  • Saltar a definiciones en librerías de terceros, incluso cuando el fuente no está versionado en el repo.
  • Encontrar todas las referencias de un símbolo en el proyecto.
  • Leer documentación hover para cualquier función, clase o tipo.

El agente pasa menos tiempo en tool calls y produce código más preciso en el primer intento. Para el desarrollador, eso es menos espera mientras el agente decompila un JAR o recorre node_modules para responder algo que el IDE ya sabe, y menos giros equivocados construidos sobre una firma mal leída. El agente razona sobre el código con el mismo entendimiento estructurado que entrega un go-to-definition del editor.

¿Cómo se instala?

1. Descargá el skill desde la página Awesome Copilot LSP Setup skill y obtené el ZIP. 2. Extraelo a ~/.copilot/skills/ corriendo unzip lsp-setup.zip -d ~/.copilot/skills/. 3. Reiniciá GitHub Copilot CLI: si ya está corriendo, escribí /exit y volvé a lanzar copilot para que tome el skill nuevo. 4. Pedile al agente que configure un language server, por ejemplo: "set up LSP for Java" o "enable code intelligence for Python". 5. Verificá con /lsp el estado del servidor y probá un go-to-definition sobre un símbolo de una dependencia.

El skill es parte del proyecto open source Awesome Copilot, así que admite contribuciones y feedback de la comunidad.