loot

¿Qué hace loot?

Cada sesión deja botín. La mayor parte muere en el registro del chat. Tu trabajo: encontrarlo, escribirlo todo, juzgarlo según evidencia en lugar de entusiasmo, y publicar solo la pieza rara que se lo merezca, después de que el usuario diga que sí.

La mayor parte del valor de loot está en LOOT.md: un registro continuo de todo lo que el usuario ha descubierto. Publicar es la excepción.

Loot es cualquier parte valiosa de la sesión, no solo descubrimientos secundarios:

Tipo	Cómo se ve	Forma habitual
Build	la app, herramienta o script sobre el que trataba la sesión	repo
Componente	una pieza que funciona fuera de este proyecto (un hook, un parser, una configuración, un prompt)	repo o gist
Técnica	un truco, arreglo o método (hizo X 4× más rápido, logró que Y funcionara localmente)	post + gist o repo
Know-how	correcciones y retroalimentación que el usuario te dio y que hicieron buena la salida	skill
Historia	el camino desde el problema hasta el resultado, incluyendo callejones sin salida	post
Datos	benchmarks, comparaciones, mediciones	post o README del repo

Una sesión a menudo contiene varios elementos. Un solo elemento a menudo merece varias formas (repo + post + demo).

Modos

Comando	Hace
/loot	escanea esta sesión, muestra la tabla, pregunta qué publicar
/loot "<tema>"	mira solo una cosa (más barato): "el truco de ffmpeg"
/loot 2, /loot all	publica el drop 2, o cada drop clasificado como Raro o mejor, sin preguntar cuáles
/loot --list	lista sesiones pasadas recientes para elegir
/loot <sesion.jsonl>	escanea una sesión pasada en lugar de la actual
/loot review	re-evalúa lo que ya está en LOOT.md (ver paso 6)

1. Escanea

Lee toda la conversación y los archivos que tocó. Para una sesión pasada, o cuando partes anteriores de esta fueron resumidas, lee la transcripción en su lugar:

node <carpeta de esta skill>/scripts/transcript.mjs list          # sesiones recientes de Claude Code + Codex
node <carpeta de esta skill>/scripts/transcript.mjs read <archivo>   # texto condensado, secretos ocultos

La transcripción de esta sesión es el archivo más nuevo en ~/.claude/projects/<proyecto>/. Si no pudiste leer más allá de un resumen, dilo en la tabla: los descubrimientos tempranos pueden faltar. Lista los candidatos. Para cada uno, escribe qué hace y la prueba de que funciona (test, benchmark, antes/después, la reacción del usuario).

Descarta un elemento cuando solo funciona en la configuración de este usuario y no se puede generalizar, cuando es mayormente código de otra persona, o cuando es trabajo privado o de un cliente del usuario. No menciones secretos, credenciales ni datos personales de la sesión en la tabla.

2. Clasifica

La clasificación es un filtro, y su trabajo es decir que no. Eres un mal juez del trabajo que acabas de ayudar a hacer: no puedes decir qué es nuevo para el mundo, y tiendes a halagar al usuario. Así que la rareza viene de la evidencia, y el juicio ocurre lejos de la conversación.

Recolecta evidencia para cada candidato:

• consulta: lo que un desconocido con este problema escribiría en un cuadro de búsqueda
• búsqueda: ejecútala (web, GitHub, npm/PyPI) y lista los resultados más cercanos con enlaces. Busca lo que hace, no su nombre. Sin herramienta de búsqueda: "no revisado".
• prueba: un test, benchmark o antes/después que realmente ocurrió en la sesión, con dónde (el comando, el archivo, el mensaje), o "ninguna". Nunca reconstruyas pruebas de memoria: las notas de IA inventan nombres, números y detalles.
• ventaja: lo que hace que el resultado más cercano no hace, medido si es posible

Clasifícalo en otro lugar. Si puedes iniciar un subagente, dale solo los candidatos y su evidencia, nunca la conversación, con este resumen: "Clasifica cada elemento según el estándar a continuación. Argumenta primero por Común y sube un elemento solo cuando su evidencia cumpla el estándar. Cuando no estés seguro, clasifica más bajo. Usa solo la evidencia dada; nunca añadas ni asumas nada. Para cualquier elemento que esté a un requisito del siguiente nivel, nombra la evidencia más barata que lo subiría." Si no puedes, escribe el caso más fuerte de que cada elemento es Común antes de clasificarlo.

Rareza	Necesita todo de	Formas
Común	cualquier cosa por debajo de Raro	una línea en LOOT.md
Raro	una consulta real; una búsqueda citada que no encontró nada equivalente, o una ventaja medida sobre el resultado más cercano; prueba de que funciona	gist, post corto, o un repo o skill pequeño
Épico	Raro, más una ventaja medida sobre una alternativa nombrada, y que funcione desde un clon limpio	repo o skill, post, demo, borradores de lanzamiento

Reglas estrictas:

• "no revisado" o "sin prueba" significa Común, por muy bien que se sienta.
• Algo equivalente existe y la ventaja no está medida: Común. Una ventaja argumentada desde los README de otros proyectos no está medida.
• Empates redondean hacia abajo.
• Casi aciertos reciben un siguiente paso. Un elemento a un requisito del siguiente nivel se etiqueta [COMÚN, casi Raro] o [RARO, casi Épico] y recibe una línea siguiente:: la evidencia más barata que lo subiría, y aproximadamente cuánto tiempo toma. Eso convierte un "no" en una tarea pendiente que el usuario puede elegir.
• Espera que casi todo sea Común. Si más de un elemento en una sesión se clasifica por encima de Común, di por qué esta sesión es la excepción.
• Común no es un fracaso. Es la entrada de diario que evita que el trabajo se pierda.

Muestra la tabla de loot, con la evidencia para cualquier cosa por encima de Común, y detente:

LOOT: 3 drops
1. [RARO, casi Épico] remotion-ae-transitions: Transiciones estilo After Effects en Remotion, completamente local
   consulta: "remotion after effects transitions"
   búsqueda: @remotion/transitions (slides, fundidos, cortinillas), un pack de plantillas de pago; ninguno hace estas
   prueba: 6 transiciones renderizadas y aprobadas en la sesión
   ventaja: no medida, así que no es Épico → gist + post corto
   siguiente: renderiza las mismas 3 tomas con @remotion/transitions y compara; luego una ejecución desde clon limpio (~45 min)
2. [COMÚN] truco de dos pasos de ffmpeg: documentado en la wiki de ffmpeg → LOOT.md
3. [COMÚN] cargador de fuentes personalizado: solo útil en este proyecto → LOOT.md
¿Publicar cuáles? (números, "all", o "none")

Muestra como máximo 7 drops, los más fuertes primero. Todo lo demás recibe una línea bajo "anotado".

Después de mostrar la tabla, agrégala a LOOT.md en la raíz del proyecto (crea si no existe), con fecha. Un drop merece una entrada completa solo si una sesión futura saldría mal, o reharía trabajo real, sin ella. De lo contrario, es una entrada de "anotado" de una línea. El diario solo es útil si se mantiene legible.

3. Forja

Para cada elemento elegido, construye la cosa terminada en una nueva carpeta fuera del historial del repositorio actual (por defecto ../<slug>, o donde diga el usuario). Lee references/forge.md para la lista de verificación de cada forma. En resumen:

• Generalízalo. Elimina nombres de proyecto, rutas hardcodeadas, detalles de cliente y código muerto. Debe funcionar desde un clon limpio con los pasos del README. Ejecútalo.
• Nómbralo. Corto, memorable, que diga el trabajo. Verifica que el nombre esté libre: gh search repos <nombre>, npm view <nombre> (salida 1 significa libre).
• Eslogan. Una línea que le diga a un desconocido qué hace y para quién.
• Logo. Simple, uno o dos colores, legible a 16px, que funcione en claro y oscuro.
• Vista previa social. Una tarjeta de 1280×640 (logo, nombre, eslogan) para que los enlaces compartidos muestren una imagen en lugar de una tarjeta de GitHub en blanco.
• README. Resultado primero, luego inicio rápido, luego cómo funciona.
• Prueba. Un test, un benchmark o un antes/después. Nunca inventes números.

Skills: si la forma elegida es una skill, sigue la habilidad skill-factory que viene junto a esta (../skill-factory/SKILL.md), entregándole la evidencia del elemento (consulta, resultados de búsqueda, prueba, ventaja) como especificación inicial. Salta los pasos 3–5 para ese elemento: skill-factory prueba, revisa y controla el lanzamiento por sí mismo.

4. Verifica (nunca lo saltes)

1. Escanea cada carpeta que publicarás en busca de secretos:

   • siempre: node <carpeta de esta skill>/scripts/scan.mjs <carpeta>
   • también, si gitleaks está instalado: gitleaks dir <carpeta>, y gitleaks git <carpeta> cuando la carpeta tenga historial de git.

   Arregla cada hallazgo, o marca un falso positivo con loot:allow en esa línea y di por qué. Revisa cada línea warn manualmente. Nunca subas historial de git existente que gitleaks no haya escaneado; sin gitleaks, publica desde un git init nuevo en su lugar.

2. Lee cada archivo que se publicará. Busca datos personales, nombres de clientes, nombres de host internos, enlaces a repositorios privados y código bajo otra licencia.

3. Muestra al usuario un manifiesto: cada destino (nombre del repo, público o privado, borrador de blog o en vivo), los archivos, el eslogan. Pide un sí claro. Un sí cubre exactamente ese manifiesto, nada más.

5. Publica

Lee references/ship.md para comandos y alternativas. Usa tus propias herramientas primero; si no, dale al usuario un comando o archivo listo para ejecutar.

• Repo: gh repo create, descripción, temas, push.
• Post: dev.to o Hashnode como borrador cuando ya haya un token configurado; de lo contrario, un archivo Markdown. Medium: Markdown más instrucciones de importación.
• Publicaciones de lanzamiento (Show HN, X, Reddit), solo Épico: borradores en una carpeta launch/ ignorada por git. Nunca las publiques.
• Termina con enlaces a todo lo publicado y cualquier cosa que quede para el usuario.

6. Revisión (/loot review)

Las clasificaciones de una sesión son una suposición. La evidencia se acumula con el tiempo:

1. Lee LOOT.md. Agrupa las entradas que son la misma cosa vista de nuevo (misma idea raíz, incluso si está redactada de manera diferente).
2. Re-clasifica un drop cuando algo cambió: apareció en 3 o más sesiones, ganó pruebas (usuarios, un benchmark, alguien lo pidió), o una nueva búsqueda ya no encuentra nada equivalente. Usa las mismas reglas de evidencia y el mismo revisor externo.
3. Muestra qué se movió y por qué. Escribe una sección "revisión" con fecha en LOOT.md; nunca reescribas entradas antiguas. Luego ofrece publicar cualquier cosa que ahora sea Raro o mejor.

Usa lo que el agente tiene

Necesidad	Mejor	Alternativa que siempre funciona
Logo / imagen de portada	tu propia generación de imágenes o un MCP de imágenes, si tienes uno	SVG escrito a mano
Escaneo de secretos	gitleaks (también cubre historial de git)	scripts/scan.mjs incluido
Video demo	Remotion (Node)	capturas de pantalla + GIF
Capturas de pantalla	una herramienta de navegador	pídele una al usuario
"¿Existe?"	búsqueda web	marca "no revisado" (lo limita a Común)
Sesiones pasadas o resumidas	scripts/transcript.mjs (Claude Code, Codex)	pídele al usuario que pegue o exporte la conversación
Clasificación independiente	un subagente que nunca vea la conversación	el caso más fuerte para Común, escrito primero
Publicar repo	CLI gh	imprime los comandos
Publicar post	la API de la plataforma con un token existente	archivo Markdown

Reglas

• Nada se hace público sin el sí del usuario sobre el manifiesto exacto.
• Nunca pidas, escribas ni almacenes credenciales. Si una herramienta no ha iniciado sesión, recurre a la alternativa.
• Nunca publiques secretos, datos personales, ni trabajo de clientes o empleadores.
• Respeta las licencias: no relicencies código que no escribiste.
• Sin pruebas inventadas: sin benchmarks falsos, usuarios, citas ni conteos de estrellas.
• Escribe con la voz del usuario del chat, no como un comunicado de prensa.