Crear y mantener una biblioteca de habilidades que funcione con cualquier IA

## Ordenar las carpetas para que los detalles de cada habilidad se carguen solo al usarla Asigna a cada habilidad su propio directorio con un archivo principal de instrucciones, los metadatos obligatorios y directorios opcionales de referencias y scripts. Conserva los ejemplos completos, el material de investigación, las plantillas canónicas y la documentación de toda la colección en ubicaciones claramente separadas. Mantén un mapa de habilidades en la raíz para que un usuario o agente pueda descubrir la colección sin cargar el cuerpo de todas las habilidades. Trata los nombres y las descripciones como el índice de inicio. Carga las instrucciones detalladas, las referencias y los scripts únicamente cuando se active una habilidad. Esta estructura reserva la atención para la tarea actual y mantiene disponible el material más profundo cuando se necesite. ## Mantener corto el archivo principal de cada habilidad y útil en cualquier herramienta Mantén el archivo principal de instrucciones de una habilidad por debajo de 500 líneas y traslada el material detallado a las referencias. Exige metadatos YAML con los campos name y description, redacta description en tercera persona, usa nombres de directorio en minúsculas separados por guiones y cuestiona el valor informativo de cada párrafo. Supón que el público es avanzado, salvo que la habilidad enseñe explícitamente los fundamentos. Redacta instrucciones independientes de la plataforma. Abstrae las herramientas específicas de un proveedor, excepto cuando una restricción de la plataforma sea esencial, y crea ejemplos portátiles en lugar de presentar pseudocódigo conceptual como código listo para producción. ## Escribir cuándo usar cada habilidad y cuándo no Incluye secciones sobre condiciones de activación, conceptos fundamentales, orientación práctica, ejemplos, directrices, problemas conocidos, integración y referencias. Cada sección de activación debe indicar los desencadenantes positivos y un límite de no activación que dirija el trabajo adyacente hacia la habilidad correcta. Da especial importancia a los problemas conocidos derivados de la experiencia, porque recogen modos de fallo que las instrucciones genéricas suelen omitir. En las instrucciones de integración, menciona otras habilidades por nombres estables en texto sin formato cuando los enlaces puedan romperse entre distintas disposiciones de instalación. ## Al cambiar una habilidad, actualizar las listas y el origen de sus cifras Al añadir o cambiar una habilidad, actualiza conjuntamente la descripción general de la colección, los manifiestos de distribución y el índice del corpus. Relaciona la habilidad con sus situaciones de activación, mecanismos de comportamiento reutilizables y afirmaciones de respaldo, para que el descubrimiento, el empaquetado y la evaluación describan el mismo artefacto. Registra la procedencia de las afirmaciones numéricas, de benchmark, volátiles o relativas al rendimiento de un proveedor. Actualiza los registros de mecanismos y afirmaciones cada vez que una habilidad introduzca un cambio de comportamiento reutilizable o una afirmación sensible a las pruebas; no dejes esas relaciones implícitas en el texto. ## Pasar revisiones automáticas antes de pedir el juicio de una IA Antes de aceptar un cambio, ejecuta las comprobaciones declaradas por el repositorio para el análisis de metadatos, el esquema y la estructura estricta del corpus, las disposiciones de instalación compatibles con distintas plataformas, la salud del cuerpo de las habilidades, los límites de activación y los benchmarks adversariales. Trátalas como controles de revisión, no como diagnósticos opcionales. Valida primero de forma determinista la estructura, la sincronización de manifiestos, la aritmética de las rúbricas, el estado de recuperación y la forma de los registros. Recurre al juicio de un modelo solo después de que pasen esas comprobaciones y no utilices un modelo para justificar un fallo estructural reproducible. ## Usar los comandos de instalación y prueba propios de cada proyecto de ejemplo No inventes un sistema de build de nivel superior cuando el repositorio no disponga de uno. Identifica el runtime y el gestor de paquetes declarados por cada ejemplo o subproyecto y usa sus propios comandos de setup, build, test, lint, format y type-check. Mantén los entornos y las dependencias limitados a ese subproyecto. Ejecuta el comando pertinente más pequeño durante las iteraciones y completa después el conjunto de controles documentado por el subproyecto antes de la revisión. Distingue la compilación, las pruebas unitarias, las pruebas asíncronas, el linting, el formateo y la comprobación estática de tipos, en lugar de tratar el éxito de un solo comando como prueba de que todos los controles pasaron. ## Avanzar cada investigación por etapas fijas con la herramienta prevista Inicializa cada ejecución de investigación mediante la herramienta de ciclo de vida suministrada, para que cree de forma coherente el archivo de estado, la entrada de la cola, el registro del hilo, la estructura de evaluación de fuentes y la plantilla de propuesta de mecanismos. Avanza por recuperación, evaluación, propuesta, revisión de novedad, validación de la ejecución, preparación para revisión y cierre mediante transiciones admitidas; nunca edites manualmente el estado de una ejecución. Valida las ejecuciones activas de forma independiente de los controles generales del repositorio. Promueve un mecanismo propuesto únicamente cuando la ejecución esté preparada, se haya registrado el revisor obligatorio y pase la comprobación de preparación. Añade la procedencia de una afirmación antes de incorporar a una habilidad una afirmación numérica, de benchmark o volátil. ## No usar IA de pago en la investigación automática hasta fijar un presupuesto Proporciona comandos deterministas para el descubrimiento, el avance de un paso, el procesamiento diario y los informes de estado, tanto si el bucle se inicia manualmente como mediante un planificador específico de la plataforma. Mantén operativa la recuperación sin llamadas a modelos de pago y no invoques modelos de pago desde bucles desatendidos hasta que exista un control presupuestario explícito. Trata las colas, los registros de runtime, las instantáneas, los informes de estado, las revisiones aplazadas, los flujos de eventos, los fallos y los directorios de ejecución ordinarios como estado operativo, no como código fuente. Nunca los incluyas en un commit, salvo en una ejecución inicial designada deliberadamente. ## Distribuir habilidades relacionadas en un solo paquete, sin copias Cuando un host almacene en caché por separado el código fuente de cada plugin, distribuye una colección de habilidades relacionadas mediante un único paquete en lugar de dirigir varios paquetes al mismo árbol de código fuente. Así se evitan cachés redundantes y se conserva un único límite coherente de versión y manifiesto. Al iniciar, expón únicamente los metadatos necesarios para el descubrimiento. Aplaza los cuerpos completos de las habilidades y sus recursos de apoyo hasta la activación, para que la amplitud del paquete no se convierta en una carga permanente para el contexto. ## Dar menos material a la IA y pedir permiso a una persona antes de enviar los cambios al repositorio compartido (push) Da prioridad a la calidad del contexto sobre su cantidad: la atención limitada y la pérdida de información en posiciones intermedias implican que añadir más material puede reducir el rendimiento. Usa subagentes para aislar la atención en trabajos acotados, no solo para imitar funciones organizativas. Mantén portátiles los ejemplos conceptuales mediante pseudocódigo independiente del lenguaje o ampliamente legible. Sitúa las pruebas deterministas antes del juicio del modelo y mantén la publicación remota bajo control humano. Los agentes pueden preparar cambios y superar todos los controles locales, pero deben obtener una aprobación humana explícita antes de ejecutar push o merge.