Remote Frog

Hace unos días, un compañero me compartió una exploración sobre una skill de Claude Code que llamó Linear Issue Enricher. La skill básicamente puntúa issues de Linear para evaluar si están listas para ser leídas y desarrolladas por un agente y las enriquece con contexto del código cuando es necesario. Soy fan de LibreChat, así que me pregunté en seguida si podría portar esto a un agente de LibreChat sin mucho dolor.

Spoiler: sí. Y es una buena prueba de concepto para escribir skills de IA una vez y desplegarlas en múltiples plataformas.

Este post recorre lo que hice, lo que funcionó, lo que no, y lo que aprendí.

TL;DR

Esto es lo que hice:

• Moví una skill de Claude Code a un agente de LibreChat y la probé en unos 20 minutos
• El proceso fue sorprendentemente directo: extraer archivos → traducir a system prompt → adjuntar archivos de referencia
• No funcionó perfectamente al primer intento — el agente se perdió con las tablas en markdown, pero tuvo un arreglo rápido.
• Es una prueba de concepto sólida de que las skills pueden moverse entre plataformas de IA con mínimo esfuerzo
• El patrón también puede ser útil: desarrollar en Claude Code, desplegar en LibreChat para acceso más amplio del equipo

El caso de uso. El Linear Issue Enricher

Primero lo primero: Linear es una herramienta de gestión de proyectos y seguimiento de tareas diseñada para equipos de desarrollo de software. Así que un issue es una tarea. Más o menos.

¿Qué es el Linear Issue Enricher?

La skill original hace algo genuinamente útil: toma un issue de Linear (a menudo escrito en un lenguaje vago y/o de negocio) y lo transforma en una especificación lista para un agente de dev. Lo hace a través de varias fases:

1. Lee el issue de Linear
2. Lo puntúa contra una rúbrica de preparación (escala 0-12)
3. Explora los repositorios y documentos relevantes para llenar los vacíos
4. Completa la especificación con todo el contexto que un agente de codificación necesitaría
5. Añade el resultado de vuelta a Linear (esto es posible según el MCP que tangas; en algunos casos, necesitarás copiar y pegar el contexto manualmente).

La skill está publicada en un repo público de GitHub. Usa una rúbrica de puntuación (ver archivo md) con cuatro criterios y clasifica los issues como Listo para Agentes, Casi Listo, Necesita Trabajo o No Preparado. Y tiene una plantilla complementaria para especificaciones enriquecidas, también en md.

El proceso de migración

Paso 1: Extraer los archivos

Echa un vistazo al repo de la skill en GitHub. Cogí cuatro archivos esenciales:

| Archivo                     | Propósito                                 |
|-----------------------------|-------------------------------------------|
| `README.md`                 | Visión general y contexto                 |
| `SKILL.md`                  | El flujo de trabajo (fases, pasos, lógica)|
| `scoring-rubric.md`         | El framework de evaluación de 4 criterios |
| `enriched-spec-template.md` | La estructura del output                  |

El archivo SKILL.md estaba particularmente bien organizado —ya tenía una estructura por fases que se traducía casi directamente en un system prompt, y eso me ahorró un par de minutos (de todos modos, yo no habría creado esa secuencia yo mismo, sino que habría pedido a un LM que la infiriera).

Paso 2: Traducir el flujo de trabajo a un system prompt

La skill original definía 8 fases:

• Fase 0: Parsear Input
• Fase 1: Obtener datos del Issue
• Fase 2: Cargar Configuración
• Fase 3: Determinar Repos Relevantes
• Fase 4: Puntuar Preparación del Issue
• Fase 5: Exploración del Codebase
• Fase 6: Producir Spec Enriquecida
• Fase 7: Presentar y Publicar

Convertí estas fases en secciones de un prompt de sistema, manteniendo la lógica pero adaptándolas a un contexto de agente conversacional. Los cambios principales fueron: (a) sugerir preguntarle al usuario qué repos explorar y (b) que el output sea para copiar y pegar manualmente, ya que no está garantizado tener acceso de escritura a Linear si el MCP es solo de lectura.

Paso 3: Usar File Context para los materiales de referencia

Aquí es donde la funcionalidad de File Context de LibreChat viene como anillo al dedo. En lugar de cascarle una copia de la rúbrica completa y la plantilla en el system prompt, podemos simplemente imitar la estructura de la skill y subir ambas tablas al File Context de LibreChat. Así…

• Tenemos un system prompt mucho más corto.
• Es más fácil de actualizar. Se puede cambiar la rúbrica o la plantilla sin tocar el prompt
• Tiene una separación más limpia —y legible al menos para humanos— entre instrucciones y materiales de referencia

Y luego, las instrucciones referencian estos archivos explícitamente:

## Archivos de Referencia

Tienes acceso a dos archivos de referencia que DEBES usar:
- **scoring-rubric.md** — Úsalo para puntuar issues en los 4 criterios (0-3 cada uno, max 12)
- **enriched-spec-template.md** — Usa esta estructura exacta para tu output final

Paso 4: Conectar las herramientas MCP

El agente necesita MCPs. Por ejemplo -pero depende de donde esté lo necesario en tu caso-:

• Linear MCP — para obtener issues (nuestra instancia es de solo lectura, que vale)
• GitHub MCP / otros — para explorar codebases
• Documentation MCP / otros — para explorar docs relevantes

Cómo puede pasar que tu MCP de Linear no tenga permisos de escritura, añadí lógica de fallback en la fase de “Presentar Resultados”:

**Intenta** usar el MCP de Linear para añadir el comentario
- **Si el MCP no tiene permisos de escritura**: Di "No pude publicar directamente.
Aquí tienes la spec lista para copiar:" y proporciónala en formato limpio

Cómo fue

Lo bueno

El flujo de trabajo se tradujo rapida y limpiamente. La estructura por fases de la skill original se mapeó casi directamente al prompt (instrucciones). La verdad es que las skills parecen estar diseñadas para ser naturalmente portables.

Además, funcionó. En el segundo intento, el agente consiguió:

• Obtener un issue de Linear
• Puntuarlo contra la rúbrica
• Explorar el repo relevante
• Generar una especificación enriquecida con marcadores [ENRICHED] para el contexto descubierto, para que puedas validarlos o eliminarlos.

El output fue genuinamente útil —identificó detalles técnicos que no estaban en el issue original y lo estructuró todo de forma que otro agente (o un humano) pudiera implementar.

Ole.

Lo no tan bueno

Creo que el agente estaba inicialmente diseñado para desarrolladores frontend. Yo trabajo principalmente con datos y usé un issue bastante complejo en el primer intento así que el agente se perdió. Nada que no se arregle en un suspiro ajustando las instrucciones.

La rúbrica de puntuación y la plantilla de spec tienen múltiples tablas markdown con estructuras similares. En la primera ejecución, el agente se confundió sobre qué tabla usar. Para ser sincero, creo que esto es más un problema de adecuación al problema que un fallo de la skill en sí.

La segunda ejecución, con un issue más adaptado y más atómico, funcionó mejor. Los issues complejos con alcance ambiguo le siguen costando —pero es un poco el sentido de la herramienta. Si el issue puntúa bajo en “Alcance Accionable”, el agente lo identifica correctamente como un gap.

Lo que he aprendido

1. Las skills de Claude Code son MUY portables, al menos a LibreChat

El enfoque estructurado por fases se traduce bien en instrucciones o system prompts. Si estás construyendo skills en Claude Code o Cursor, probablemente ya estás escribiendo algo que puede moverse a otras plataformas.

2. File Context > Fuerza bruta (copiarlo todo)

Usar archivos adjuntos para materiales de referencia es más limpio que meterlo todo a presión en el texto de las instrucciones. También en caso de upgrade, te permite actualizar la rúbrica o la plantilla sin modificar las instrucciones principales.

3. Es buena idea anticipar que falte alguna capacidad

Mi MCP de Linear es solo de lectura, por lo que la funcionalidad de “publicar en Linear” no se activa automáticamente. Pero con un fallback (“aquí tienes la spec, copia y pégala”), el agente sigue siendo útil.

Nota: Acuerdaté de diseñar para escenarios degradados.

4. Las tablas complejas necesitan desambiguación clara

Cuando tus materiales de referencia tienen múltiples tablas con pinta similar, el modelo se puede liar. Algunas estrategias:

• A corto plazo: instrucciones explícitas
• A largo plazo: rehacer la documentación de tus tablas para que sea completamente (o lo más posible) legible por agentes.

5. El patrón: ¿desarrollar una vez, desplegar en todas partes?

Este ejercicio sugiere un flujo de trabajo que puede ser útil:

1. Desarrollar skills en Claude Code / Cursor / donde te guste más
2. Portarlas a LibreChat para acceso más amplio del equipo (sin CLI, solo una interfaz de chat)

Pero sugiere también que portar skills / artefactos similares a la inversa o entre multiples plataformas debería ser igualmente sencillo. El esfuerzo de conversión es bajo ==> El trabajo gordo ya está hecho cuando escribes la skill por primera vez y lo testas.

Reflexión final

Fue un ejercicio interesante. No porque el resultado sea perfecto —no lo es— sino porque demuestra que el ecosistema de skills de IA es interoperable. Una skill de Claude Code bien estructurada puede convertirse en un agente de LibreChat en 20 minutos. Y eso tiene su gracia.