Convertir un documento en un skill

Tutorial · 6 min de lectura

El conocimiento que quieres que tenga un agente casi siempre está ya escrito en algún sitio: un PDF de incorporación, una guía de estilo en Word, un manual de incidencias en Markdown. Lo que falta no es el conocimiento. Es que un documento está escrito para una persona que lo lee de principio a fin, mientras que un skill tiene que funcionar para un agente que la carga a mitad de una tarea y necesita actuar.

Skilnu puede hacer la primera pasada de esa conversión. Sube un documento y recibes un borrador de SKILL.md: el modelo mental central, las definiciones, las pautas, reestructurados como instrucciones. No se publica nada. Lo lees, corriges lo que no encaja y publicas cuando estés conforme, igual que con cualquier otro skill.

1. Sube el documento

En la aplicación, abre + New skill y pulsa Draft from a document, junto a «Subir SKILL.md». Elige tu archivo y espera: tarda más que el resto de la aplicación, porque hay que leer y reescribir un documento entero.

Estos formatos funcionan: .pdf, .docx, .txt, .md, .markdown, .rst y .adoc.

Cualquier otro se rechaza antes de subirse. Si tienes un formato que no está en esta lista, expórtalo primero a PDF: esa vía está bien cubierta.

2. Envía una sección, no una biblioteca

Hay un límite de unos 40.000 caracteres de texto extraído, aproximadamente un capítulo largo. Por encima de eso la subida se rechaza en lugar de recortarse en silencio: un skill redactado a partir de los primeros 40.000 caracteres de un libro de 300 páginas, entregada como si viniera del libro entero, sería peor que un error.

Limita menos de lo que parece, porque lo que hace buena a un skill es justamente lo que cabe: un tema coherente. «Nuestros estándares de revisión de código» es un skill. «Todo el manual de ingeniería» es una carpeta llena de ellos. Si tienes un documento grande, divídelo por capítulos y redacta cada uno por separado: obtendrás mejores skills que las que habría producido una sola pasada sobre el conjunto.

3. Los PDF escaneados necesitan OCR primero

Un PDF que en realidad son fotografías de páginas no tiene texto que extraer, así que el borrador vuelve con un mensaje que lo explica en lugar de con un skill vacía. Pásalo antes por cualquier herramienta de OCR —la mayoría de aplicaciones de PDF traen «reconocer texto»— y sube la versión con texto.

Una forma rápida de saberlo: abre el PDF e intenta seleccionar una frase. Si no puedes, es una imagen.

4. Lee el borrador con atención

El borrador aparece en el formulario de redacción, con el nombre y la descripción rellenados desde su propio frontmatter. Es una primera pasada de un modelo que leyó tu documento una vez, así que léelo como leerías el primer intento de un compañero competente, no como trabajo terminado.

Tres cosas merecen comprobarse siempre:

¿Ha conservado lo concreto? Commands, thresholds, names of internal tools, the actual numbers. These are the most useful part of a skill and the easiest thing to lose when prose gets condensed.

¿Se ha inventado algo? The draft is told to stay inside what the document supports, but if your document was vague somewhere, check that the draft was vague in the same place rather than confidently filling the gap.

¿Son instrucciones o es un resumen? The failure mode to watch for is a draft that describes what the document says instead of telling the agent what to do. If a section reads like a book report, rewrite it as a rule.

5. Publícalo

Edita el formulario hasta que estés conforme y publica con normalidad. A partir de ahí es un skill corriente: se puede versionar, otros skills pueden depender de él, puedes compartirla con tu equipo y añadirla a tu biblioteca MCP.

Hacerlo desde un agente

El mismo flujo está disponible por MCP, como dos herramientas, porque el archivo tiene que llegar al almacenamiento entre una y otra. Pide una URL de subida, envía los bytes y luego pide el borrador:

get_document_upload_url(filename="handbook.pdf")
  -> { upload_url, document_key }

PUT the file's bytes to upload_url
  (no auth header -- the URL is already signed)

draft_skill_from_document(document_key=...)
  -> { name, description, skill_md }

La versión para agentes acepta un argumento instructions adicional que el formulario web no expone, y aquí resulta muy útil: «céntrate en el capítulo 3», «escríbelo para alguien que empieza», «conserva todos los ejemplos de código». Se suma a tus instrucciones de compilación permanentes en lugar de sustituirlas.

Como en todo lo demás, draft_skill_from_document solo redacta un borrador. Publicarlo es una llamada publish_skill aparte, así que un agente no puede convertir un documento en un skill publicado sin que tú veas antes el borrador.

Cuánto cuesta

Cada borrador consume una unidad de tu cuota diaria de compilación, en el modelo que hayas elegido en Ajustes: el mismo presupuesto que usa publicar con compilación. Un borrador fallido que nunca llegó al modelo, como un archivo no admitido o uno que supera el límite de longitud, no consume nada.

El documento que subes es espacio temporal. Se elimina en cuanto se genera el borrador, con éxito o sin él, y lo que de algún modo sobreviva desaparece en 24 horas. Nunca forma parte del skill publicado: solo el borrador que revisas lo hace.

Para qué sirve esto

Los mejores candidatos son documentos que ya codifican una forma de trabajar: una guía de estilo, una lista de revisión, un manual de incidencias, el capítulo de un libro técnico que quieres que un agente aplique en lugar de citar. El material de consulta sin procedimiento dentro —un volcado de API, un glosario, una hoja de cálculo exportada a PDF— produce un skill pobre, porque no hay pautas que extraer de la fuente.

Una buena prueba antes de subir nada: ¿podría alguien leer este documento y luego hacer algo de otra manera? Si la respuesta es sí, saldrá un skill. Si solo es algo que se consulta, probablemente no.