- git-memento es una herramienta de extensión que registra automáticamente en los commits de Git las sesiones de código generadas por IA, guardando como git notes el historial de conversación de IA correspondiente a cada commit
- Al indicar el ID de sesión de IA al hacer commit, el resumen se guarda en
refs/notes/commits y la conversación completa en refs/notes/memento-full-audit, por separado, para asegurar al mismo tiempo trazabilidad y privacidad
- Soporta varios proveedores de IA como Codex y Claude, y al generar resúmenes puede aplicar skills personalizadas por el usuario para controlar la calidad de las notas del commit
- Se integra con GitHub Actions para ofrecer comentarios automáticos en commits, validación de compuertas CI y traslado automático de notas al fusionar (merge-carry)
- Compatible con Windows/Mac/Linux. Es una herramienta que aumenta la transparencia de la generación de código con IA y permite la auditabilidad del historial de contribuciones de IA en entornos colaborativos
Resumen de git-memento
git-memento es una extensión de Git que registra las sesiones de programación con IA a nivel de commit
- Al hacer commit, organiza el contenido de la conversación de la sesión de IA y lo guarda como notas en Markdown
- Deja en cada commit el origen y el contexto conversacional de la sesión de IA, para poder rastrear el proceso de generación de código
- Soporta Codex de forma predeterminada, y también se pueden configurar otros modelos de IA como Claude
- Se publica bajo licencia MIT y se distribuye como un solo ejecutable basado en NativeAOT
Comandos y funciones principales
- Con
git memento init se inicializa la configuración por repositorio y la información del proveedor de IA se guarda en .git/config
- El comando
git memento commit añade una nota de sesión al mismo tiempo que el commit
- Si se usa la opción
--summary-skill, el resumen y la sesión completa se guardan por separado
- El resumen se registra en
refs/notes/commits y el registro completo en refs/notes/memento-full-audit
git memento amend permite añadir una nueva sesión a un commit existente o modificarlagit memento audit verifica si faltan notas dentro de un rango de commits y valida la metadatagit memento doctor revisa la configuración, las referencias de notas y el estado de sincronización remota
Gestión y sincronización de notas
- Con
git memento share-notes se envían las notas a un repositorio remoto (origin, etc.)
git memento notes-sync fusiona de forma segura las notas remotas y crea respaldos
- Sincroniza tanto
refs/notes/commits como refs/notes/memento-full-audit
git memento notes-carry traslada las notas a un nuevo commit después de un rebase o squashgit memento notes-rewrite-setup activa la configuración para el traslado automático de notas
Integración con GitHub Actions
- El repositorio incluye una GitHub Action reutilizable
mode: comment — lee las notas del commit y genera comentarios automáticamentemode: gate — verifica en la etapa de CI si faltan notas y bloquea el build en caso de errormode: merge-carry — traslada las notas al commit de merge cuando se fusiona un PR
- Cada modo está definido en
action.yml e incluye el artefacto para publicación en Marketplace (dist/note-comment-renderer.js)
- Los PR con la etiqueta
ignore-notes omiten la verificación de compuerta y dejan un comentario de “Notes ignored”
Formato de notas y control de versiones
- Las notas se guardan con el formato
git notes add -f -m ""
- Para soportar múltiples sesiones se usan etiquetas de versión(``) y separadores de sección
- Los mensajes del usuario se etiquetan con el nombre de usuario de Git, y las respuestas de la IA con el nombre del proveedor
- Las notas antiguas de una sola sesión se actualizan automáticamente cuando hace falta para mantener la compatibilidad
4 comentarios
En proyectos privados exporto la sesión, la incluyo en el commit y, en los públicos, la commiteo solo si considero que hace falta sí o sí un archivo de resumen.
Al fin y al cabo también hay datos personales... y, aunque depende de la herramienta, por sesión fácilmente pasa de 10 MB... así que no me convence subirlo así nomás.
¡Pero estamos viviendo en una era en la que el almacenamiento en disco es más barato que nunca!
Opiniones de Hacker News
Cuando escribo código con IA, empiezo con un archivo project.md
Ahí describo el resultado que quiero y hago que la IA escriba un plan.md con base en eso
Después modifico plan.md varias veces y, cuando el plan que quiero está listo, genero una lista de tareas detallada y la agrego al final de plan.md
Cuando ya estoy completamente satisfecho, le indico a la IA que ejecute los pendientes y que los complete hasta el final sin seguir preguntando
Al final, hago commit de project.md, plan.md y de todo el código
Así, plan.md se vuelve una especie de artefacto reproducible, de modo que más adelante un modelo más avanzado pueda modificarlo o encontrar errores a partir de eso
design lo escribo por funcionalidad y dejo explícitas las preguntas sin resolver
plan lo gestiono con la estructura
plan/[feature]/phase-N-[description].md, y si me topo con límites de compilación o ejecución, me detengoEn la etapa de debug planteo hipótesis sobre causas posibles, las valido con logging/tracing y luego corrijo
Con este método he tenido casi 100% de éxito tanto en proyectos nuevos como legacy
La desventaja es que se acumulan demasiados archivos markdown, pero como el historial pasado sigue siendo útil para cambios futuros, aún no lo he automatizado
Vale la pena revisar GitHub spec-kit
Cuando haces que el modelo itere entre investigación de mercado y revisión de propuestas, termina haciendo diseño de prompts en un lenguaje que él mismo puede entender
Hace poco descubrí que XML afecta el comportamiento de Claude, así que estoy replanteando la estructura de GuardRails
Enlace al post de presentación
Cuando el plan queda listo, creo un “context.md” para usarlo más adelante si necesito revertir un plan equivocado
Todavía no me ha hecho falta en la práctica, pero conceptualmente me parece útil
Lo que sí, todavía no lo incluyo en el repo porque no tengo claro dónde deberían ir estos archivos
Me da curiosidad saber dónde guardan estos archivos md por tarea
En mi opinión, esto es como preguntar “¿hay que hacer commit de cada línea?”
Al final, la clave es para quién es el registro
La mayoría de las sesiones tienen mucho ruido, intentos fallidos e información innecesaria
Lo importante es el resultado de la sesión, no el proceso en sí
Aun así, el spec inicial o el primer prompt sí tienen valor. Conviene resumir eso y dejarlo en el mensaje del commit o en un archivo markdown
Podría tomar sesiones pasadas como contexto de aprendizaje y continuar el trabajo actual
En especial, puede ayudar a entender las limitaciones del modelo y encontrar puntos donde el código se desvió de la intención del usuario
Al final, creo que registrar toda la entrada humana es importante para el avance de los modelos open source
Debe poder obtenerse el mismo resultado incluso incluyendo las condiciones iniciales y el ruido
Si no, el mantenimiento futuro del código se vuelve un juego de adivinar intenciones
Artículo relacionado
Hace una semana propuse una idea parecida (enlace)
Pero también hubo muchas opiniones en contra: los proyectos con IA no se generan a partir de una sola entrada, sino en un proceso conversacional, así que es difícil convertirlos en artefactos como el código fuente
Aun así, están apareciendo demasiados proyectos generados en Show HN y el ruido ya es serio
No se pueden excluir por completo, pero en su estado actual me interesan menos
Sigo pensando cómo debería abordar este problema la comunidad
Hago commit de research.md y plan.md para usarlos como un diccionario vivo de arquitectura y funcionalidades
Pongo el nombre de la funcionalidad como prefijo en el nombre del archivo para que Claude pueda cargar rápido el diseño relacionado
Blog de referencia
Proyectos que antes eran interesantes ahora se hacen con demasiada facilidad
Hacer que la gente lea logs largos de sesión no es la solución. La capacidad de resumir y planear se vuelve aún más importante
El verdadero valor del vibe coding está en ver el proceso de intento y error
Resulta más interesante cuando no solo subes el resultado final, sino también el proceso de creación y la explicación
Por eso me gustaría que existiera una categoría tipo [Creations] aparte de [Show HN]
Por ejemplo: un motor de ajedrez simple iría en [Creations], mientras que un motor de ajedrez hecho con 1k iría en [Show HN]
PerfBoard y Lerc son ejemplos de eso
La sesión es solo un artefacto intermedio, no hace falta incluirla en el resultado final
Si importa por qué se hicieron los cambios en el código, lo correcto es organizarlo en el mensaje del commit o en documentación
En el momento del commit no sabes qué preguntas se hará un lector futuro
Por eso prefiero guardar la sesión y luego generar un resumen a partir de preguntas
Git AI usa este enfoque
Hoy en día los ingenieros trabajan tan rápido que a veces, pasada una semana, ya ni recuerdan por qué hicieron algo así
Los prompts de investigación conviene resumirlos, y los prompts de generación de código conviene guardarlos tal cual
Así se garantiza la reproducibilidad y la posibilidad de revisión
El plan termina reflejando hasta el proceso de corrección de errores y se vuelve un documento útil para la siguiente iteración
Cada repo intercambia mensajes con otros y así gestiona solicitudes de funcionalidades
Guardo tanto la conversación original como la memoria comprimida semánticamente para reordenar specs y requisitos
Los logs de sesión son en su mayoría ruido
Son una sucesión de intentos fallidos y retrocesos, así que ponerlos junto al commit es como guardar el historial del navegador
Lo importante es un mensaje de commit que contenga la intención y las restricciones
Si la IA escribió el código, lo central no es la conversación sino por qué se le pidió eso
Al final, quizá el problema no sea guardar la sesión, sino el hábito de descuidar los mensajes de commit
Aunque use IA, yo mantengo un proceso de diseño tradicional
Requisitos → casos de uso → diseño de clases → definición de restricciones → ejecución con IA
Así se conserva la capacidad humana de juicio arquitectónico, mientras la IA acelera la implementación repetitiva
Si en vez del log de sesión incluyes en el commit documentos UML o de restricciones como estos, puedes dejar mucho más clara la intención y el contexto
Creo que los desarrolladores de 2026 deberían mantener una estructura de colaboración con clase como esta
Esto se parece a decidir si hacer squash de los commits o no
Si prefieres squash, solo importa el resultado y no dejas el proceso
Si no, registras el recorrido en sí
Las sesiones de IA igual: son útiles para depurar el proceso de pensamiento, pero quien prefiere un historial limpio no necesariamente quiere verlas
En la práctica, lo razonable es gestionar las sesiones aparte del repo
He oído que Mercurial o Fossil tienen mejor soporte para algo así
En el vibe-coding, más que el código mismo, el prompt muestra el rastro del pensamiento
Que vaya o no en git es otro tema, pero sí tiene valor dejarlo accesible
En esos casos no hace falta ver el proceso en tiempo real
Pero si el código fue escrito completamente por IA, entonces sí hace falta publicar los prompts
Yo también he extraído sesiones
Hay cierto riesgo de perder información, pero la legibilidad y la accesibilidad mejoran muchísimo
Como mínimo, creo que hay que guardar los prompts resumidos de la sesión
La revisión de código hecha por IA es menos estricta que la humana, y la intención solo está en los prompts
Si no, se vuelven a repetir los mismos errores
El valor del code review está en aprender y mejorar, pero como la IA no aprende, el registro de prompts tiene que cumplir ese papel
Además, también hace falta para evaluar habilidad con prompts o formar a juniors
Nosotros no incluimos en el commit las pulsaciones del teclado, los clics en menús ni los intentos de depuración
Si guardas todas las conversaciones, hay demasiado ruido
En cambio, sí es realista dejar al menos documentos con la intención y los supuestos
Es como preguntar: “¿deberíamos incluir el historial de búsquedas de Google en el commit?” — obviamente creo que no
En cambio, conviene dejar solo un resumen de razones, supuestos y alternativas
Del mismo modo, tampoco hace falta el log de cuando el modelo se perdió con un problema trivial
> “¿Habría que incluir el historial de búsquedas de Google en el commit?” Es básicamente la misma pregunta; yo diría que obviamente no.
Me gusta este comentario