dll2llm y Revit: dar a Codex documentación de la API que tienes instalada
Si voy a pedirle a Codex código para Revit, quiero que consulte la API de la versión que tengo instalada. Una respuesta puede parecer razonable y utilizar un método de otra versión. dll2llm propone aprovechar las DLL de esa instalación para generar una referencia que el agente pueda consultar. Me interesa precisamente esa cercanía entre la documentación y las bibliotecas con las que después habrá que compilar.
A partir de la presentación de Autodesk y del repositorio, veremos qué genera la herramienta y cómo preparar una comparación útil. Esta es una revisión documental del procedimiento; no he realizado una compilación ni una prueba funcional dentro de Revit.
Tabla de contenidos
Qué información aporta una referencia generada desde las DLL
Una DLL administrada de .NET contiene información sobre los tipos y miembros que expone. El proyecto dll2llm utiliza reflexión para recorrer esa superficie y producir documentación en Markdown. Esto permite obtener una referencia de clases, métodos, propiedades y otros miembros a partir de los ensamblados elegidos. Para una API grande, la utilidad está en organizar esa información para consultar una parte concreta cuando hace falta, en lugar de incluirla entera en cada conversación.
En Revit, RevitAPI.dll contiene la capa principal de acceso al modelo y RevitAPIUI.dll añade capacidades relacionadas con la interfaz. Seleccionar ambas puede tener sentido si vas a desarrollar un complemento que necesite las dos. No significa que debas dar al agente todos los archivos instalados por el producto. Interesa empezar por los ensamblados que corresponden al trabajo y dejar que la herramienta resuelva las dependencias de acuerdo con su funcionamiento documentado.
La salida incluye SKILL.md, INDEX.md y archivos temáticos organizados por espacios de nombres. La entrada del skill orienta al agente; el índice permite localizar tipos y las fichas desarrollan la información. Esta distribución facilita una consulta progresiva: buscar primero dónde está una clase y leer después su referencia. También ofrece algo útil para revisar una respuesta: se puede preguntar qué archivo utilizó el agente y contrastar si el miembro que propone aparece allí.
Las descripciones XML añaden una capa que las firmas no explican por sí solas. Saber que un método recibe determinados argumentos ayuda a escribir una llamada, pero no siempre aclara sus condiciones de uso o sus errores. El README advierte que, sin XML, puede haber estructura y firmas sin las descripciones correspondientes. Una referencia aparentemente extensa puede resultar insuficiente justo en el comportamiento que necesita tu herramienta.
La procedencia de versión es otra ventaja. Si generas desde una instalación identificada, puedes registrar esa base y revisar el material cuando actualices el producto. Eso no elimina todos los errores del agente, pero reduce una ambigüedad: ya no depende únicamente de ejemplos de internet que quizá se escribieron para otra versión. La documentación generada sigue necesitando contexto de uso, y el código seguirá necesitando compilación y pruebas.
Preparar la generación sin separar las DLL de su entorno
El README consultado exige .NET 10 SDK y, para la mayoría de APIs de escritorio Autodesk, Windows x64 con el producto instalado. La instalación completa importa porque hay dependencias administradas y nativas junto a las DLL principales. Copiar dos ensamblados a una carpeta de otro equipo puede permitir empezar una inspección y fallar al cargar determinados tipos. Para este procedimiento, las rutas deben apuntar a la instalación real del producto.
También conviene separar la versión del SDK que necesita dll2llm de los requisitos del complemento que después vas a construir. Utilizar .NET 10 para generar documentación no determina automáticamente cómo debe configurarse el proyecto del add-in para tu versión de Revit. Son herramientas con funciones diferentes. Mezclar ambas decisiones puede producir una documentación válida y un proyecto que no cumple las condiciones de ejecución de la aplicación donde debe cargarse.
La instalación documentada de la herramienta utiliza dotnet tool install --global dll2llm. Una vez disponible el comando, puedes seleccionar los ensamblados y una salida escribible. Este ejemplo de PowerShell conserva explícitamente la carpeta de salida para que no termine junto a las DLL del producto:
dll2llm `
"C:\Program Files\Autodesk\Revit 2026\RevitAPI.dll" `
"C:\Program Files\Autodesk\Revit 2026\RevitAPIUI.dll" `
--output ".\revit-api-skill"
Las rutas son ilustrativas: hay que ajustarlas al año y a la ubicación instalados. Después de ejecutar, interesa revisar los avisos de dependencias y comprobar el contenido de la salida. La existencia de una carpeta no demuestra que todos los tipos se hayan cargado ni que las descripciones estén completas. Una revisión pequeña puede buscar una clase conocida, comprobar sus miembros y seguir una referencia a su clase base.
Antes de conectar el agente, abre un tipo que conozcas en la documentación generada y comprobaría sus miembros y su versión. Es un control pequeño, pero permite detectar una generación incompleta o una DLL equivocada antes de utilizar esa referencia para escribir un complemento.
Incorporar el skill a Codex y comprobar que realmente lo consulta
La documentación oficial de skills de Codex permite disponer de skills del repositorio en .agents/skills. En un proyecto de trabajo, la carpeta generada puede situarse como .agents/skills/revit-api, conservando el archivo SKILL.md y las referencias que utiliza. La estructura importa: mover solo el archivo de entrada y dejar sus documentos en otra ubicación puede romper precisamente el recorrido de consulta que se pretende facilitar.
La descripción del skill ayuda a decidir cuándo debe utilizarse. Si tienes documentación de Revit y de servicios APS, ambas deberían indicar su ámbito. Una pregunta sobre el documento activo en Revit necesita una referencia distinta de otra sobre proyectos en la nube. Cargar más material sin diferenciarlo no garantiza una mejor respuesta; también puede hacer más difícil reconocer qué fuente corresponde al problema.
Codex utiliza el nombre y la descripción para descubrir capacidades y lee las instrucciones completas cuando selecciona el skill. Esto permite mantener una entrada breve y referencias más extensas. No hay que copiar miles de líneas de documentación dentro de AGENTS.md para que estén disponibles. Las instrucciones del proyecto pueden explicar cómo verificar la versión y cuándo consultar el recurso, mientras el detalle de la API permanece en los archivos que le corresponden.
La comprobación práctica consiste en pedir al agente que localice un tipo concreto y muestre la referencia que ha utilizado. Si no reconoce el skill, hay que revisar su ubicación y metadatos antes de evaluar la calidad del código que produzca. Si lo reconoce pero responde sin consultar los documentos relevantes, todavía no tienes evidencia de que ese recurso haya participado en la respuesta. Instalar una carpeta y observar una mejora posterior no demuestra por sí solo una relación entre ambas cosas.
Mantén la documentación generada separada del código del complemento y anota a qué instalación corresponde. Para compartir el ejercicio, basta con explicar cómo generarla con las bibliotecas propias; no hace falta redistribuir las DLL de Revit junto al ejemplo.
Comparar dos resultados sin confundir compilación con funcionamiento
Un ensayo pequeño puede pedir una herramienta de lectura: obtener las puertas del documento activo y devolver sus identificadores, sin modificar parámetros. La tarea es suficientemente concreta para revisar el código y observar el resultado. También obliga a resolver aspectos reales de la API: localizar el documento, filtrar la categoría adecuada y trabajar con los tipos devueltos. Es preferible a una petición amplia como «crea un complemento útil», cuyo resultado resulta difícil de comparar.
Para estudiar la aportación del skill, el mismo enunciado se utiliza en dos sesiones nuevas con el mismo modelo y configuración. Una tiene acceso a la referencia y otra no. Hay que evitar que la segunda herede la solución o los errores de la primera, y registrar otras fuentes que el agente consulte. Si una sesión también obtiene documentación web y la otra no, la comparación ya no permite atribuir toda diferencia al skill local.
El análisis puede empezar por los nombres y firmas de los miembros propuestos. Después se revisan los errores de compilación y las correcciones necesarias. Finalmente se comprueba el complemento dentro de la versión de Revit elegida, sobre un modelo de prueba. Estas etapas responden a preguntas distintas: si la referencia existe, si el código cumple el contrato de compilación y si hace lo que se pidió en el entorno donde debe funcionar.
Un código compilable puede ejecutar una consulta en un contexto incorrecto, seleccionar elementos que no corresponden o interpretar mal un parámetro. Si más adelante incorpora cambios, también habrá que resolver transacciones y condiciones de edición. La documentación de las firmas ayuda a localizar las piezas, pero la regla BIM y la forma de combinarlas siguen formando parte del desarrollo. La introducción a la API de Revit sitúa esa transición entre una llamada aislada y una herramienta que otra persona puede utilizar.
La comparación propuesta consiste en repetir el mismo encargo con y sin esa referencia y registrar errores de API, correcciones y resultado de compilación. Después quedaría la ejecución en Revit. Así podremos ver en qué ayuda la documentación generada y en qué siguen haciendo falta contexto y pruebas.
Qué hacer cuando la referencia no responde a la pregunta
El README señala que los miembros heredados no se repiten en todas las subclases. Si buscas una propiedad en una ficha y no aparece, puede estar documentada en la clase base. Es un caso donde leer el índice y seguir la jerarquía aporta más que pedir al agente que pruebe otro nombre. También muestra por qué una referencia navegable necesita instrucciones de consulta: la ausencia de una entrada en una página no demuestra que el miembro no exista.
Otra limitación aparece cuando falta documentación de comportamiento. La reflexión puede mostrar que una operación está disponible sin explicar cuándo es válida, qué estado necesita o qué consecuencia tiene sobre el modelo. Ahí hay que volver a la documentación oficial, a ejemplos compatibles con la versión y a pruebas controladas. Añadir otra descripción generada por IA a partir de la firma no sustituye esa comprobación; puede limitarse a redactar de forma convincente lo que todavía falta saber.
Para APIs cloud, la fuente tiene otra forma. APS Docs Skill ayuda a localizar documentación del portal, mientras dll2llm parte de ensamblados .NET. Mantener ambos recorridos separados facilita pedir al agente una justificación útil: qué versión o página respalda la llamada y qué parte sigue necesitando verificación. El resultado deseable es un desarrollo más trazable, sin tratar la documentación instalada como garantía automática de corrección.
Puedes empezar con una tarea de lectura y una versión concreta de Revit. Si la referencia ayuda a localizar los tipos correctos, el siguiente paso será compilar y comprobar el comportamiento en el modelo. Generar la documentación tiene sentido cuando podemos seguir ese recorrido hasta el uso de la API.
Respuestas