Experience Pack
Una frase: cada proyecto mantiene su propio libro de bitácora de experiencia; una prueba de límite destila la parte portable; solo la parte portable viaja entre proyectos.
Funciona con entrada tipeada o dictada: descripciones desordenadas, coloquiales, multilingües de "lo que acaba de salir mal" son materia prima válida para una entrada del libro de bitácora — el skill las estructura, el usuario solo confirma.
Las dos capas
| Capa | Archivo | Propietario | Reglas de contenido |
|---|---|---|---|
| Bitácora | EXPERIENCE.md en la raíz del proyecto | el proyecto | fechado, concreto, detalles específicos del proyecto permitidos; solo experiencia de proceso — nunca verdad del producto, nunca un registro de decisiones |
| Portable | el archivo de lecciones portables del proyecto (ej. LESSONS.md) y/o el paquete de referencia de este skill | viaja | abstracto, libre de nombres de producto, verdadero en un proyecto DIFERENTE leído por un desconocido |
Pipeline: algo sucede → entrada en la bitácora (mismo día, mientras duele) → paso periódico de destilación → lecciones portables. Las decisiones estratégicas y de producto nunca viajan: la experiencia se hereda, las decisiones mueren.
Protocolo A — REGISTRAR (bitácora)
Adjudicación de raíz primero. La bitácora vive en la raíz del proyecto — así que confirma que HAY una raíz de proyecto antes de escribir. Si el directorio de trabajo actual es un directorio personal, Escritorio, Descargas o cualquier otra ubicación que no sea de proyecto, pregunta a qué proyecto pertenece esta experiencia y escribe la bitácora allí. Nunca crees un EXPERIENCE.md en un directorio personal o de Escritorio. Si no se puede establecer un directorio de proyecto, o el destino no tiene permisos de escritura, no descartes la entrada en silencio: genera la entrada completamente formateada como texto copiable e indica al usuario dónde debería ir eventualmente.
Crea EXPERIENCE.md en la raíz del proyecto el primer día (o en el primer uso). Añade una entrada cuando ocurra cualquiera de estos eventos: un incidente costó tiempo/dinero/confianza real; un método funcionó visiblemente; un revisor independiente detectó algo que el autor pasó por alto; un patrón de colaboración tuvo éxito o fracasó; el usuario corrigió el rumbo del agente.
Formato de entrada:
### YYYY-MM-DD — título
**Lo que pasó:** hechos, concretos.
**Lo que hicimos:** la respuesta, concreta.
**Lo que funcionó / lo que falló:** ambos, honestamente.
**Costo:** tiempo / tokens / confianza / retrabajo.
**¿Portable?** sí → <slug-de-la-lección> | aún no | no (específico del proyecto).
Reglas: registra experiencia de proceso, no hechos del producto; si el espacio de trabajo tiene reglas de higiene de contaminación (sustantivos prohibidos), la bitácora las obedece; nunca modifiques retroactivamente ni reescribas entradas antiguas — añade correcciones como nuevas entradas. Escribe las entradas de la bitácora en el idioma en que vive el proyecto (sigue el hábito existente del usuario; si se desconoce, pregunta una vez).
Reglas vinculantes (destiladas de los proyectos adoptantes del paquete):
- Registrar es parte de haber terminado. La corrección de un incidente no puede declararse completa hasta que exista su entrada en la bitácora — la bitácora es un control, no un diario. (Un adoptante temprano rellenó 8 entradas en un día porque nada obligaba a escribir en el momento del incidente; los apagafuegos nunca dejan tiempo para diarios.)
- Las importaciones de arranque son legítimas, la retro-modificación silenciosa no. Al adoptar el paquete en un proyecto con historial: fecha cada entrada por su fecha de INCIDENTE y declara la importación en una nota fechada al inicio de la bitácora. Una entrada fechada en el pasado sin una importación declarada es fabricación.
- Higiene de distribución. La bitácora contiene información interna del proyecto. En un repositorio con un remoto público, ignora
EXPERIENCE.mden git por defecto; publica solo la capa portable verificada por la prueba de límite. - Capacidad de descubrimiento. Añade una línea de referencia al archivo de verdad principal del proyecto (CLAUDE.md / AGENTS.md / mapa del sistema / documento de estado) para que un agente sin contexto pueda ENCONTRAR la bitácora; una bitácora indescubrible no registra nada para la siguiente sesión.
- Una bitácora ignorada por git necesita una ruta de escape declarada. Ignorar la bitácora en git (regla anterior) también la elimina de la recuperación por clonación/envío. Una bitácora ignorada por git DEBE tener un canal de respaldo o sincronización declarado — un repositorio o rama privados, una carpeta sincronizada, una copia programada; el usuario elige — registrado como una línea en la nota de cabecera de la bitácora. Sin ello, un cambio de máquina o una reclonación borra en silencio la memoria del proyecto: cambiar de máquina se convierte en amnesia que nadie nota hasta que el próximo incidente se repite.
Protocolo B — DESTILAR (prueba de límite)
Para cada entrada de la bitácora marcada como "¿Portable? sí/aún no", ejecuta las pruebas en orden:
- Prueba de sustitución — elimina todo nombre propio y número específico. ¿La declaración sigue enseñando algo? Colapsa → es una decisión, muere.
- Mecanismo vs elección — ¿Dice cómo funcionan o fallan las cosas (mecanismo → hereda), o quién/qué/cuánto fue elegido (elección → muere)?
- Prueba de re-derivación — ¿Podría un desconocido inteligente re-derivarla del contexto del nuevo proyecto? Si solo podría venir de la estrategia del proyecto antiguo, es la estrategia antigua hablando — muere.
- Prueba de costo hundido — ¿Su único valor es que se gastó esfuerzo en ello? Muere.
- Prueba de verificabilidad — ¿Verificarla requiere un sustantivo muerto? Abstrae o déjala morir.
Los supervivientes se reescriben como una línea imperativa abstracta + por qué + cómo aplicar, etiquetados con procedencia ("proyecto anterior, destilado · fecha"). Escribe la capa portable en inglés (o bilingüe): la bitácora puede usar cualquier idioma en que viva el proyecto, pero las lecciones portables viajan a desconocidos — el lenguaje local del proyecto las deja varadas. Los elementos ambiguos por defecto MUEREN — la bitácora los mantiene recuperables para un pase posterior. DEGRADACIÓN (raro): un artefacto con forma de estrategia reingresa a otro proyecto solo como una HIPÓTESIS explícita con una condición de revalidación, y solo por decisión del usuario — nunca en silencio.
Protocolo C — COMPARTIR / APLICAR (otro proyecto aprende de este)
- En el proyecto receptor: lee
references/rebuild-experience-pack.md(la saga empaquetada de este skill) y/o el archivo de lecciones portables del proyecto fuente — nunca el libro de bitácora del proyecto fuente, ni sus archivos de verdad, ni su estrategia. - Inicia el
EXPERIENCE.mddel proyecto receptor (Protocolo A, incluyendo adjudicación de raíz). - Recorre los cinco consejos del paquete como una lista de verificación de configuración; adopta lo que aplica; registra las desviaciones como la primera entrada de la bitácora del proyecto receptor.
- Las lecciones adoptadas ingresan al proyecto receptor etiquetadas con procedencia; son restricciones de ingeniería, no decisiones del usuario — el usuario puede reclasificar cualquiera de ellas.
Límites — lo que este skill nunca hace
- Nunca copia estrategia, hechos del producto, personas, precios, canales, nombres de clientes o identidades de cuentas entre proyectos — en ninguna dirección.
- Nunca trata la bitácora como un registro de decisiones; las decisiones viven en los archivos de verdad/decisiones del proyecto con sus propias reglas de procedencia.
- Nunca edita otros skills ni la configuración global del usuario.
- Nunca lee material en cuarentena/archivado de un proyecto para "enriquecer" un paquete; la entrada de destilación es solo la bitácora y los archivos vivos.
Relación con skills adyacentes
- conclude-rounds — revisa las rondas de la conversación actual. Un usuario que dice "复盘" o "hagamos una revisión" sobre ESTA conversación pertenece allí; este skill es dueño de las retrospectivas a nivel de proyecto que sobreviven a la conversación.
- iteration-close — cierra una iteración de una dirección en curso (destilar, eliminar lastre, etiquetar, sembrar). Ejecuta el Protocolo B de experience-pack como parte de ello si ambos están instalados; iteration-close es dueño del ritual de cierre. Advertencia que ambos skills deben honrar: "el historial de git es el archivo" solo es válido para archivos rastreados. El material no rastreado/ignorado por git (IP privada en un repositorio público) no tiene archivo — ponlo en cuarentena bajo una regla local explícita (ej.
_retired/) antes de cualquier purga; borrarlo es pérdida permanente, no limpieza. - diagnose-project-rebuild — cuando una dirección es REEMPLAZADA, la prueba de límite aquí es la misma prueba usada para decidir qué sobrevive; el skill de reconstrucción es dueño del diagnóstico y los mecanismos de purga, y toma SOLO la capa portable de este skill como entrada.
- Este skill es agnóstico al producto y debe permanecer así: si un sustantivo del proyecto aparece alguna vez en este archivo o sus referencias, eso es un defecto — elimínalo.
Notas del motor
Nada aquí depende del tiempo de ejecución de un solo proveedor. "Sesión fresca" y "sonda de contexto cero" significan cualquier instancia de agente iniciada sin el contexto anterior — un nuevo chat, un sub-agente o una segunda herramienta. Cuando no hay un tiempo de ejecución de skills disponible, aplica los protocolos manualmente: los formatos de archivo y las pruebas anteriores son el skill.
Referencia
references/rebuild-experience-pack.md — la experiencia empaquetada y libre de sustantivos de una saga real de cinco reconstrucciones con contaminación: las seis puertas de contaminación, el método de restablecimiento de bloqueo de fuente, la pila de verificación de tres sondas, el protocolo de colaboración multi-IA y los cinco consejos de prevención.