David-Li0406/meta-skill-evloving

Gestor de Archivos de Habilidades Locales

Propósito

Mantener los archivos de habilidades locales personales del usuario como un sistema de memoria ligero y auto-mejorable. El objetivo predeterminado no es producir habilidades genéricas listas para el mercado; es preservar el comportamiento reutilizable que ayude a este usuario, este equipo o este espacio de trabajo en sesiones futuras. Un buen candidato puede codificar preferencias de flujo de trabajo personales, convenciones de proyecto, contratos de estilo, elecciones de herramientas o puertas de revisión que no serían útiles para otros usuarios, siempre que sea reutilizable para el propietario previsto y aprobado.

Esta habilidad no depende de código específico del proyecto, servidores, almacenes vectoriales, bases de datos o diseños de almacenamiento. Opera solo en carpetas de habilidades locales ordinarias:

<raíz-de-habilidad>/
  <nombre-de-habilidad>/
    SKILL.md
    agents/openai.yaml   (opcional)
    scripts/             (opcional)
    references/          (opcional)
    assets/              (opcional)

Usa esta habilidad para decidir cuándo una sesión contiene material de habilidad reutilizable, encontrar si ya existe una habilidad similar, y luego descartar, mejorar, fusionar o crear una habilidad local. El modelo debe iniciar esta verificación cuando aparezcan señales; no debe esperar a que el usuario lo solicite. La verificación debe mantenerse ligera y no bloqueante a menos que el usuario solicite explícitamente centrarse en el mantenimiento de habilidades.

Coordinación de Habilidades Relacionadas

Esta habilidad posee el ciclo de vida de la decisión: cuándo extraer, si descartar, si mejorar o fusionar, y dónde escribir. Coordina con las habilidades cercanas cuando están instaladas:

• Usa skill-creator para la estructura de nueva habilidad, nomenclatura, colocación de recursos, agents/openai.yaml y validación.
• Usa skill-improvement o guía de mejora equivalente para la iteración de habilidades existentes, pruebas de prompts, análisis de fallos, ajuste de descripción de disparadores y comparación antes/después.
• Usa skill-finder, find-skills, o herramientas de descubrimiento equivalentes para buscar ecosistemas de habilidades locales o externos antes de crear un duplicado.
• Toma prestados patrones de auto-mejora solo como heurísticas de decisión: triaje de eventos, deduplicación, recurrencia, prioridad, comprobaciones de valor y puertas de promoción. No adoptes las rutas de almacenamiento, suposiciones de demonio o estructura de código de otra habilidad a menos que el usuario lo solicite.
• Si esas habilidades auxiliares no están disponibles, aplica los procedimientos integrados a continuación. No te bloquees por la falta de habilidades auxiliares.
• No permitas que las habilidades auxiliares debiliten el límite de extracción: solo deben guardarse cambios de capacidad reutilizables y respaldados por evidencia del usuario.

Seguridad y Consentimiento

Las habilidades locales pueden influir en el comportamiento futuro del agente y pueden incluir scripts ejecutables. Trata las ediciones de habilidades como cambios de comportamiento duraderos.

• No instales, importes ni actives habilidades de terceros sin el consentimiento del usuario.
• No añadas capacidades sorprendentes, acceso a la red oculto, manejo de credenciales, exfiltración de datos o comandos destructivos.
• Si una habilidad añade scripts o integraciones de herramientas, haz visible su propósito en SKILL.md.
• Al editar una habilidad que pueda compartirse con un equipo, preserva las políticas de la organización y pregunta antes de cambiar el comportamiento sensible a la seguridad.
• Trata cada candidato como personal por defecto; márcalo como team o public solo cuando la evidencia respalde esa audiencia más amplia.
• No publiques, recomiendes como ampliamente reutilizable ni elimines el ámbito personal de una habilidad específica del usuario sin la aprobación explícita del usuario.
• Antes de la primera nota de aprendizaje persistente o escritura de habilidad en una nueva convención local, informa al usuario qué ruta se escribirá y solicita aprobación.
• No modifiques silenciosamente este gestor autoskill durante el mantenimiento rutinario. Mejóralo solo cuando el usuario solicite explícitamente mejorar esta habilidad.

Raíces de Habilidades

Antes de escribir algo, identifica dónde viven las habilidades locales.

• Usa primero una ruta explícita proporcionada por el usuario.
• De lo contrario, verifica raíces comunes como ${CODEX_HOME}/skills, ~/.codex/skills, ./skills, .agents/skills, y cualquier directorio de habilidades del espacio de trabajo actual que contenga */SKILL.md.
• Si existe exactamente una raíz plausible, úsala.
• Si existen múltiples raíces plausibles y el objetivo es ambiguo, pregunta al usuario qué raíz mantener.
• Nunca reorganices raíces de habilidades no relacionadas ni edites habilidades fuera de la raíz elegida.

Política de Disparadores

Usa una política de disparadores de tres capas:

1. Escaneo silencioso: después de cada turno sustancial del usuario, pregúntate brevemente si el turno contiene una preferencia personal, regla, corrección, flujo de trabajo, fallo o problema de calidad de habilidad reutilizable.
2. Verificación de extracción: cuando se active un disparador a continuación, clasifica la experiencia, asigna evidencia y valor, busca habilidades similares y pruébala contra el límite de extracción.
3. Escritura/actualización: solo edita archivos de habilidades locales después de que el candidato pase el límite, la raíz de habilidad objetivo esté clara y el usuario apruebe el cambio exacto.

El modelo debe iniciar proactivamente los escaneos y las verificaciones de extracción. No preguntes al usuario "¿debería buscar una habilidad?". Pregunta solo cuando la raíz objetivo sea ambigua, la edición sobrescribiría un comportamiento incierto, o el usuario deba aprobar una instalación externa o un script sensible.

Ciclo de Vida del Candidato

Mantén el ciclo de vida separado de cualquier sistema de almacenamiento particular: observa una señal, opcionalmente pide al usuario que elija un título/tema candidato, redacta el candidato, deduplica por patrón, decide descartar/guardar_nota/mejorar/fusionar/crear, muestra la habilidad o diff completa propuesta, luego aplica el cambio aprobado más pequeño y valida.

Deduplica por familia de tareas, disparador, herramientas, modo de fallo, contrato de salida y habilidad objetivo en lugar de redacción exacta. No crees una base de datos privada, demonio, programador o almacén oculto en segundo plano como parte de esta habilidad.

Puerta de Selección de Título

Antes de la extracción completa, cuando el tema reutilizable sea ambiguo o haya varias habilidades plausibles, muestra 2-5 títulos concisos de capacidad reutilizable con razones de evidencia de una línea más ninguno de estos y tema personalizado. Si el usuario elige un título o ingresa un tema, trátalo solo como dirección: vuelve a ejecutar el límite de extracción y la búsqueda de habilidades similares para esa dirección, descártalo si falla, o muestra el SKILL.md/diff completo propuesto para aprobación final si pasa. Si el usuario elige ninguno de estos, descarta o guarda una nota no persistente; no escribas archivos.

Consistencia de Idioma

Para nuevas habilidades, escribe títulos candidatos, SKILL.md propuesto, agents/openai.yaml y recursos pequeños en el idioma dominante de la evidencia del usuario; la entrada en chino produce habilidades en chino, la entrada en inglés produce habilidades en inglés. Para actualizaciones o fusiones, mantén el idioma dominante de la habilidad objetivo a menos que el usuario solicite explícitamente traducirla; si la evidencia mixta hace que el idioma sea ambiguo, pregunta antes de redactar. No predetermines el contenido extraído de la habilidad al inglés.

Ejecución en Segundo Plano

La extracción y el mantenimiento de habilidades no deben bloquear la tarea principal del usuario.

• Trata las comprobaciones de extracción, la búsqueda de habilidades similares, la redacción de candidatos y la preparación de evaluación de disparadores como trabajo de mantenimiento en segundo plano siempre que sea posible.
• El trabajo en segundo plano puede preparar candidatos, encontrar habilidades similares y redactar diferencias, pero no debe escribir, actualizar, eliminar, instalar ni activar habilidades sin confirmación del usuario.
• Continúa primero con la solicitud principal del usuario; no hagas que el usuario espere por la extracción de habilidades a menos que el usuario haya solicitado explícitamente centrarse en el mantenimiento de habilidades.
• Muestra los resultados en segundo plano solo cuando haya una decisión candidata procesable, una diferencia de archivo propuesta o una pregunta de aclaración/consentimiento.
• Ejecuta como máximo un trabajo de mantenimiento de habilidades en segundo plano por conversación activa a menos que el usuario solicite un lote; pon en cola o combina señales adicionales.
• No inicies búsquedas costosas, evaluaciones amplias o reescrituras grandes en primer plano. Usa primero comprobaciones ligeras, luego difiere la validación más profunda a una pausa natural o un pase de mantenimiento explícito.
• Si el entorno de ejecución no puede ejecutar realmente trabajo en segundo plano, emúllalo difiriendo la verificación de mantenimiento hasta después de que la respuesta actual esté completa o la siguiente pausa natural.
• Nunca bloquees la entrega del trabajo solicitado por el usuario solo para terminar la extracción del candidato, a menos que el trabajo solicitado sea el mantenimiento de habilidades en sí mismo.

Puerta de Confirmación

Se requiere confirmación del usuario antes de que cualquier archivo de habilidad sea creado, actualizado, eliminado, importado, instalado, activado o reescrito sustancialmente. Redacta primero, pregunta después: después de cualquier selección de título/tema, nunca preguntes "¿debería añadir/actualizar una habilidad?" hasta que el contenido o cambio propuesto ya esté escrito para su revisión.

Para crear, muestra antes de escribir:

• nombre de habilidad propuesto y ruta objetivo
• audiencia prevista: personal, team o public, más límites de portabilidad
• por qué el candidato pasó el límite de habilidad reutilizable
• nivel de evidencia, señal de recurrencia, prioridad y señal de valor
• habilidades similares verificadas y por qué esto no es un duplicado
• contenido completo propuesto de SKILL.md
• agents/openai.yaml completo propuesto y cada script, referencia o texto de activo propuesto cuando dichos archivos sean lo suficientemente pequeños para revisar en línea; para activos grandes, muestra la lista exacta de archivos, propósito, procedencia y la diferencia o manifiesto generado

Para mejorar o fusionar, muestra antes de escribir:

• ruta exacta de la habilidad objetivo
• tipo de decisión: mejorar o fusionar
• por qué el cambio pertenece a esa habilidad existente
• nivel de evidencia, señal de recurrencia, prioridad y señal de valor
• una diferencia unificada completa, o texto completo antes/después para cada sección cambiada cuando no esté disponible una diferencia unificada
• cada archivo que se añadiría, modificaría, eliminaría o dejaría intacto
• plan de validación o comando a ejecutar después de la aprobación

Solicita una aprobación clara de sí/no solo después de mostrar el artefacto completo propuesto o la diferencia. Si el usuario no aprueba, no edites la habilidad; informa el candidato como diferido o descartado.

Disparadores Inmediatos

Ejecuta una verificación de extracción inmediatamente, o en la siguiente pausa natural si el usuario está esperando la tarea principal, cuando ocurra cualquiera de estos:

• El usuario corrige, rechaza o refina el enfoque del modelo de una manera que debería afectar tareas similares futuras.
• El usuario da una preferencia duradera, contrato de salida, flujo de trabajo, regla de nomenclatura, regla de herramienta o puerta de calidad.
• Un comando, script, integración o flujo de trabajo falla y la sesión descubre una solución reutilizable.
• El agente repite trabajo no trivial de configuración, scripting, transformación o validación que debería convertirse en un recurso reutilizable.
• Una habilidad local similar se disparó de menos, de más o produjo una guía incompleta.
• La sesión revela una referencia, plantilla, script o lista de verificación faltante que evitaría un esfuerzo repetido futuro.
• El usuario usa lenguaje orientado al futuro como "recuerda esto como una habilidad", "guarda este flujo de trabajo", "actualiza la habilidad local", "la próxima vez, hazlo de esta manera", "este es mi proceso estándar" o "crea una habilidad a partir de esta conversación".

Aún así, trata la extracción como una verificación, no un requisito: a menudo, ningún cambio de habilidad es el resultado correcto.

No extraigas cuando el usuario dice que la regla es temporal, pide no recordarla, o solo quiere una respuesta única.

Verificaciones Programadas

Usa verificaciones programadas para capturar aprendizaje gradual que ningún turno individual hace evidente:

• Verificación de longitud de conversación: después de aproximadamente 6 mensajes sustanciales del usuario, 12 turnos totales, o 2-3 intentos de tarea distintos desde la última verificación.
• Verificación de tokens/volumen: después de un gran bloque de nuevo contexto, especialmente cuando la conversación pueda ser pronto resumida o compactada.
• Verificación de límite de tarea: cuando se completa un entregable, finaliza un bucle de depuración, se acepta un plan o el usuario cambia a una nueva tarea.
• Verificación de fin de sesión: antes de la respuesta final de una sesión sustancial, revisa si algo debería ser descartado, mejorado, fusionado, creado o anotado.

Mantén las verificaciones programadas ligeras. Normalmente deberían ocurrir en silencio y solo aparecer al usuario cuando haya una decisión procesable o una aclaración necesaria.

Amortiguación y Agrupación

Previene la extracción repetida ruidosa:

• No vuelvas a verificar la misma señal repetidamente en una sesión.
• Agrupa múltiples señales débiles hasta un límite de tarea o verificación programada.
• Crea o actualiza como máximo una habilidad por verificación a menos que el usuario solicite explícitamente un lote.
• Prefiere guardar_nota o descartar para señales límite hasta que la repetición fortalezca la evidencia.
• Si un candidato está cerca pero aún no es suficientemente reutilizable, recuerda la justificación en la nota de finalización en lugar de crear una habilidad.
• Combina disparadores simultáneos en un solo pase de mantenimiento en segundo plano.
• Cuando compitan múltiples candidatos, maneja primero el fallo repetido de mayor prioridad o la preferencia confirmada por el usuario.

Triaje de Experiencia

Antes de cambiar habilidades, clasifica la experiencia de la sesión. Las categorías duraderas son error, corrección, mejor_práctica, brecha_de_conocimiento y preferencia. resultado_único significa que la sesión produjo trabajo útil pero ningún cambio de proceso duradero.

Solo las categorías duraderas pueden convertirse en cambios de habilidad, y solo después de pasar el límite de extracción. Los resultados únicos no deben ser promovidos.

Puerta de Valor y Prioridad

• Prioridad P0: previene comportamiento inseguro, destructivo, sensible a la privacidad o que falla repetidamente.
• Prioridad P1: previene un error recurrente significativo, un disparador perdido, una mala fusión o un flujo de trabajo repetido costoso.
• Prioridad P2: mejora la calidad, velocidad o claridad para una familia de tareas recurrente.
• Prioridad P3: mejora de conveniencia o estilo con evidencia limitada.

Promueve por valor duradero, no por novedad. El valor debe ser explicable como fiabilidad, seguridad, velocidad, calidad, consistencia o reducción de trabajo repetido. Si ninguna dimensión de valor es clara, descarta o guarda una nota no persistente.

Cambia una palanca de comportamiento a la vez al mejorar una habilidad existente: redacción del disparador, paso del flujo de trabajo, puerta de validación, colocación de recursos o restricción de seguridad.

Reglas de Promoción

No conviertas cada experiencia en una edición de habilidad. Promueve experiencias deliberadamente:

• Promueve inmediatamente cuando el usuario dice explícitamente que la regla debería aplicarse la próxima vez.
• Promueve inmediatamente cuando una corrección previene un fallo repetido grave, una acción insegura o un flujo de trabajo destructivo.
• Promueve después de la repetición cuando el mismo error, corrección o mejor práctica aparece en múltiples tareas similares. Como defensa…

[truncado para traducción]