Cómo convertimos el conocimiento técnico de Orbitant en contenido publicable usando IA

En Orbitant existe una cultura de conocimiento compartido que no es habitual en una consultora de nuestro tamaño. Toda la organización, en sus respectivos departamentos —especialmente Ingeniería—, documenta decisiones técnicas, debate enfoques en Slack, presenta en sesiones de Knowledge Sharing semanales y se cuestiona mutuamente lo que está haciendo en proyectos reales.

Ese conocimiento tiene un valor genuino para otros profesionales del sector. El problema es que a menudo se dispersa: hilos de Slack difíciles de seguir cuando nuevas conversaciones los desplazan, debates técnicos que se interrumpen con otras noticias que generan sus propias conversaciones, sesiones grabadas que se guardan en Drive y rara vez vuelven a ser revisitadas, etc.

Ante esta situación, nos preguntamos: ¿Cómo podemos usar la Inteligencia Artificial para evitar perder todo este conocimiento? Así fue como ideamos un pipeline de automatización de contenidos con IA que ya hemos empezado a construir.

Con esta iniciativa buscamos poner en práctica aquello que nos identifica como empresa tecnológica —ese enfoque AI-first— en un departamento que, a priori, no desarrolla software y, con ello, crear las condiciones para que cualquier persona de la compañía pueda convertir su propio conocimiento en un artículo publicable sin tener que dominar las guías editoriales, el SEO o el tono de marca.

Marketing ha hecho el trabajo de procedimentar, diseñar las instrucciones y hacer demos para que el flujo sea accesible. Pero el contenido siempre será de quien lo generó.

Una cultura de conocimiento que merece ser pública

La materia prima existe: tenemos múltiples fuentes de ideas, pero las que generan mayor volumen de material de forma más constante y periódica son las sesiones de Knowledge Sharing y las conversaciones en canales de Slack dedicados a la IA, a la ciberseguridad o al open source.

Ahí es donde ocurre el pensamiento real: por ejemplo, alguien plantea si el clean code sigue siendo relevante cuando los agentes escriben el código y en cuarenta mensajes hay tres o cuatro posiciones técnicas bien argumentadas con datos de proyectos reales. El problema, por tanto, no es la falta de ideas o contenidos. Es la distancia entre ese conocimiento que se comparte de forma habitual y un artículo publicado.

Esa distancia implica: identificar qué partes de la conversación tienen valor externo, estructurarlo como artículo, aplicar las guías de estilo y tono de Orbitant, asegurarse de que cumple los requisitos de SEO, traducirlo al inglés para la audiencia internacional y validar que la traducción preserva la precisión técnica. Cada uno de esos pasos requiere un conocimiento específico que la persona que generó el contenido original no tiene por qué poseer.

El conocimiento ya estaba. La fricción era el problema

La primera tarea no fue construir nada. Fue mapear el workflow completo: de dónde vienen las ideas, quién valida qué, qué herramientas se estaban utilizando, dónde se perdía el contenido. Ese trabajo de análisis, que hice junto a Ulises Gascón, está recogido en el documento de diseño del pipeline y fue lo que permitió identificar dónde tiene más impacto la automatización: en la generación del borrador inicial y en la traducción, los dos pasos más repetidos y más costosos en tiempo para alguien que no se dedica a escribir de forma profesional.

De una sesión KS a un artículo publicado

Tomamos las sesiones de Knowledge Sharing (KS) como punto de entrada principal del pipeline, ya que tienen una periodicidad concreta —se celebran semanalmente— y un workflow muy definido. En nuestras KS una persona del equipo presenta durante 45 minutos algo en lo que está trabajando o que ha aprendido y el resto puede plantear preguntas durante dicha exposición o al final.

Cada sesión genera material técnico de primera mano, apoyado en assets que su autor ha creado para la ocasión (diapositivas, demo, landings…). El flujo para convertirlo en contenido publicado funciona así:

1. Marketing revisa la sesión —transcripción o grabación— para determinar qué ángulo trabajar y qué keyword SEO tiene sentido.
2. La transcripción llega a Claude con las skills de Orbitant cargadas, que genera el borrador en español siguiendo las guías editoriales y de SEO.
3. El borrador entra a GitHub como Pull Request, donde la persona que presentó la sesión revisa y valida su precisión técnica. Marketing también entra en esta fase para revisar el texto.
4. Una vez que todas las personas involucradas han realizado comentarios, quien firma el artículo valida la versión final.
5. Marketing vuelve a hacer una última revisión antes de pasar a traducción.
6. Claude traduce al inglés con una estrategia de keyword propia para el mercado angloparlante y el contenido entra a una segunda PR para que el autor valide también la versión en inglés.
7. El contenido aprobado en ambos idiomas pasa a creación de assets y publicación en WordPress.

La validación técnica siempre será una tarea de quien generó el conocimiento. Lo que cambia es que el borrador ya existe cuando llega a sus manos: estructurado, con las referencias SEO aplicadas y en el tono de Orbitant. Su revisión se vuelve mucho más concreta. Marketing, por su parte, mantiene puntos de control a lo largo de todo el proceso porque es el guardián de la identidad y la voz de Orbitant hacia el exterior.

Marketing ha hecho el trabajo de procedimentar, diseñar las instrucciones y hacer demos para que el flujo sea accesible. Pero el contenido siempre será de quien lo generó.

El mismo flujo se aplica cuando se detecta una conversación de Slack con valor de publicación. A diferencia de las KS, el punto de entrada no es periódico: alguien del equipo avisa a marketing de que hay material valioso o marketing lo identifica directamente al revisar los canales. A partir de ese momento, el hilo completo va como input a Claude y el proceso de validación sigue los mismos pasos que para una KS.

Este flujo también abre la puerta a otra casuística que todavía no hemos explotado del todo: que cualquier persona de la compañía grabe una nota de voz describiendo un problema técnico al que se ha enfrentado —sin jerarquizar ideas, en lenguaje oral—, la transcriba y la pase al agente para generar una primera versión del artículo. El conocimiento no tiene que empezar siendo texto bien estructurado para terminar siendo un artículo publicable.

Las skills: infraestructura editorial con el stack de ingeniería

Lo más interesante de lo que estamos construyendo no son los agentes. Son los archivos que definen cómo se comportan. Las skills son archivos Markdown que contienen las instrucciones que el agente lee antes de hacer su trabajo. Hemos construido cuatro para el workflow editorial:

• blog-post-create — genera borradores en español a partir de cualquier input bruto (transcripción de KS, hilo de Slack, nota de voz transcrita)
• blog-post-review — hace revisión editorial y SEO antes de publicar
• blog-post-translate — adapta el artículo al inglés con estrategia de keyword propia para ese mercado
• orbitant-tone — define la voz de Orbitant con ejemplos concretos de qué hacer y qué evitar

Cada skill codifica decisiones editoriales que antes solo existían en la cabeza de las personas de marketing: cómo atribuir las voces cuando el artículo viene de una conversación con varios participantes, cuándo usar primera persona del singular frente al plural, qué palabras y construcciones se apartan de la voz de Orbitant, indicaciones específicas de puntuación para evitar los vicios más comunes de los modelos de IA, qué campos SEO son obligatorios y cuáles son sus reglas exactas.

El comportamiento del agente es configurable sin tocar código

Si el agente genera artículos que no encajan en el tono y estilo fijados en las skills porque no se habían previsto —por ejemplo, en primera persona del plural cuando el firmante debería ser una persona concreta—, se añaden nuevos criterios para elegir quién firma y en qué voz escribe. O, por ejemplo, si detectamos que usa construcciones vacías que no suenan a Orbitant, se añaden a una lista de términos a evitar con alternativas concretas. La skill no es un prompt que se escribe una vez. Es un documento vivo que mejora con cada uso.

El ciclo de mejora es deliberadamente el mismo que el del desarrollo de software:

1. Usas la skill para generar contenido real
2. Identificas un patrón de error o un comportamiento que no se ajusta
3. Editas el archivo Markdown en VS Code
4. Abres una Pull Request en GitHub con el cambio documentado
5. El equipo revisa, aprueba, y cualquiera que use la skill a partir de ese momento se beneficia de la mejora

En Orbitant no solo se genera conocimiento técnico: se comparte de forma continua. El reto no es crear más contenido. Es asegurarnos de que ese conocimiento no se quede dentro.

Este ciclo funciona porque las herramientas son las mismas que usa el equipo de ingeniería: VS Code, terminal, GitHub. Y no es algo nuevo: marketing llevaba ya tiempo trabajando los contenidos del blog directamente en GitHub —como prueba de concepto— para facilitar la visibilidad del equipo técnico sobre los artículos en proceso y hacer la validación más accesible para personas que ya trabajan en ese entorno.

El desarrollo de las skills se ha construido sobre esa misma base, lo que hace que la mejora de las instrucciones del agente sea un proceso trazable, reversible y colaborativo, con el mismo flujo de revisión y aprobación que el código. Las skills se distribuyen como un plugin de Claude, accesible desde la interfaz web de Claude.ai, desde VS Code con la extensión de Claude y desde la terminal con Claude Code.

Cualquier persona de la compañía que quiera generar un borrador tiene acceso al mismo conjunto de instrucciones editoriales sin necesidad de configurar nada. Pero que las skills funcionen también desde CLI abre una posibilidad que va más allá del uso individual: las máquinas también pueden ejecutarlas. Al combinar Claude Code, las skills y GitHub Actions, podemos automatizar pasos del pipeline que hasta ahora requerían intervención manual —como lanzar la revisión editorial y de SEO de un artículo cada vez que se abre una Pull Request—. El mismo conjunto de criterios que usa una persona de marketing para revisar un borrador es el que ejecuta el agente de forma automática en CI.

Lo que viene en el roadmap

El flujo que tenemos hoy no solo funciona para las KS sino que puede aplicarse a varias casuísticas, como hilos de conversación generados en Slack o transcripciones de audios. Además, está prevista la automatización de la detección de temas candentes: un agente que escuche los canales activamente, clasifique las conversaciones según su potencial y cree las entradas en Notion de forma automática. En estos momentos, Marketing lo registra manualmente, pero esta automatización ya está en el roadmap.

El objetivo final no es que marketing publique más. Es que la persona que sabe de lo que habla tenga herramientas para convertir ese conocimiento en contenido publicable sin depender de que alguien de marketing lo reescriba desde cero, manteniendo siempre el rigor técnico de quien lo generó y la coherencia de marca que garantiza el equipo de marketing.