Le doy estrella a un repo, lo clono, lo dejo a medio funcionar y paso al siguiente problema. Tres meses después encuentro la misma carpeta otra vez y no recuerdo por qué lo agarré, si alguna vez lo usé realmente, o si cloné la misma herramienta dos veces con otro nombre. Con más de treinta repos, eso deja de ser una broma y empieza a costar tiempo real.
¿Por qué no basta un README por repo?
Un README te dice para qué lo construyó el autor. No dice nada sobre por qué lo agarraste tú, si realmente lo estás usando, o si ya tienes otras tres herramientas haciendo exactamente lo mismo.
Esa es la parte que nadie escribe, porque nadie la escribe para repos que no son suyos. Clonas algo útil, lo haces funcionar una vez, y el contexto de por qué desaparece en cuanto cierras la terminal. Multiplica eso por 30 repos sentados en la misma carpeta y obtienes un cementerio al que te da miedo limpiar, porque no estás seguro de qué es estructural y qué es peso muerto.
Nada de eso aparece en ningún README individual. Solo aparece cuando algo lee a través de todo lo que has recolectado, en un horario, sin que te acuerdes de revisar.
¿Qué obtendrás al final?
Una bóveda, dos carpetas:
1found-tools-vault/2├── notes/ # una nota markdown por cada repo que has clonado3│ ├── some-scraper-tool.md4│ ├── some-telegram-lib.md5│ └── ...6└── memory/7 └── PORTFOLIO.md # aquí escriben las cuatro pasadas entre repos
Markdown simple en el disco. Ábrelo en Obsidian, o léele con cat desde la terminal. Sin base de datos, nada que no puedas leer tú mismo.
¿Cómo configurarlo?
En Mac o Linux:
1mkdir -p ~/found-tools-vault/notes ~/found-tools-vault/memory
En Windows, PowerShell:
1New-Item -ItemType Directory -Force -Path "$HOME\found-tools-vault\notes","$HOME\found-tools-vault\memory"
Apunta el Bucle 1 y el Bucle 2, abajo, a esta carpeta y la configuración está lista. Todo lo que sigue es lo que le dices a Claude que haga dentro.
¿El stack: las mismas tres piezas, solo apuntando al código de otros?
La bóveda. Una carpeta de Obsidian, una nota por herramienta que hayas clonado, más una carpeta para las pasadas entre repos.
La fuente. Cada repo en tu carpeta de clones, ya sea que lo uses a diario u olvides que existe.
El cerebro. Claude, dividido por tarea. El modelo barato lee el repo y su README. Sonnet hace los juicios: ¿es un duplicado de algo que ya agarraste, y realmente vale la pena el espacio en disco?
Bucle 1: una nota por herramienta, escrita por Claude, no por ti
Importante, antes de ejecutar esto en algo real:
- Nunca dejes que este bucle empuje código, instale dependencias o ejecute algo de la herramienta misma. Siempre solo lectura.
- why_i_grabbed_it se llena a partir de tus propias notas, commits o uso en otros proyectos, no se adivina desde el README del repo.
- Si no puedes determinar si estás usando una herramienta, escribe la nota con estado: unclear en lugar de saltártela.
1TRIGGER: nuevo repo clonado en la carpeta, o una vez al día2PASOS:3 1. Lee el repo: README, package.json / requirements.txt, fecha4 del último commit upstream, y verifica si está referenciado5 en algún lugar de tus otros proyectos (imports, configs, scripts)6 2. Escribe o actualiza notes/<nombre-del-repo>.md con:7 ---8 repo:9 what_it_does:10 why_i_grabbed_it:11 last_upstream_commit:12 referenced_in_my_projects: []13 status: in-use | shelved | duplicate | unclear14 ---15 ## Qué hace realmente16 ## Por qué lo agarré17 ## ¿Lo estoy usando realmente?18VERIFICAR: cada campo lleno, "referenced_in_my_projects" verificado19 contra uso real, no asumido20PARAR: verificación pasa, o 2 reintentos, luego marcar para revisión manual
Esto solo ya vale la pena construirlo incluso sin el Bucle 2. La primera vez que leas 30 de estas notas una tras otra, la mitad te sorprenderán, ya sea porque olvidaste que estabas usando la herramienta, o porque nunca lo hiciste.
Una nota de herramienta generada, al lado de la carpeta clonada real que describe. Este es el contexto que de otro modo nunca escribirías.
¿Cómo se ven 30 repos encontrados una vez que el Bucle 1 ha funcionado?
Una lista que Claude regenera cada vez que clonas algo nuevo, extraída directamente de las notas:
- github.com/author/scrape-lite - in-use, último commit upstream hace 2 días, referenciado en: proyecto feed-reader
- github.com/author/tg-bot-kit - in-use, último commit upstream hace 5 días, referenciado en: dos de mis bots
- github.com/author/quick-scheduler - shelved, último commit upstream hace 41 días, referenciado en: ninguno
- github.com/author/api-wrapper-x - in-use, último commit upstream hace 1 día, referenciado en: un proyecto
- github.com/author/rss-to-json - duplicate, último commit upstream hace 3 días, referenciado en: ninguno (misma función que scrape-lite)
- github.com/author/cheap-queue - in-use, último commit upstream hace 6 horas, referenciado en: dos proyectos
- github.com/author/webhook-relay-lib - shelved, último commit upstream hace 96 días, referenciado en: ninguno
- github.com/author/simple-cache - in-use, último commit upstream hace 2 días, referenciado en: tres proyectos
- github.com/author/old-scraper - abandoned upstream, último commit upstream hace 340 días, referenciado en: ninguno
- github.com/author/notify-me - unclear, último commit upstream hace 12 días, referenciado en: no estoy seguro
- github.com/author/token-utils - in-use, último commit upstream hace 1 día, referenciado en: un proyecto
- github.com/author/quick-parser - duplicate, último commit upstream hace 8 días, referenciado en: ninguno (misma función que rss-to-json)
- github.com/author/tiny-orm - shelved, último commit upstream hace 55 días, referenciado en: ninguno
- github.com/author/rate-limiter - in-use, último commit upstream hace 3 días, referenciado en: dos proyectos
- github.com/author/config-loader - in-use, último commit upstream hace 4 días, referenciado en: la mayoría de mis proyectos
- github.com/author/legacy-fetch - abandoned upstream, último commit upstream hace 400+ días, referenciado en: ninguno
- github.com/author/env-check - in-use, último commit upstream hace 9 días, referenciado en: un proyecto
- github.com/author/pretty-logs - shelved, último commit upstream hace 70 días, referenciado en: ninguno
- github.com/author/proxy-list - unclear, último commit upstream hace 20 días, referenciado en: no estoy seguro
- github.com/author/backoff-lib - in-use, último commit upstream hace 6 días, referenciado en: dos proyectos
- github.com/author/dead-simple-db - shelved, último commit upstream hace 88 días, referenciado en: ninguno
- github.com/author/quick-hash - in-use, último commit upstream hace 1 día, referenciado en: un proyecto
- github.com/author/retry-wrapper - duplicate, último commit upstream hace 14 días, referenciado en: ninguno (misma función que backoff-lib)
- github.com/author/format-time - in-use, último commit upstream hace 2 días, referenciado en: la mayoría de mis proyectos
- github.com/author/quick-mailer - shelved, último commit upstream hace 50 días, referenciado en: ninguno
- github.com/author/health-check-lib - in-use, último commit upstream hace 5 días, referenciado en: dos proyectos
- github.com/author/dotenv-plus - in-use, último commit upstream hace 3 días, referenciado en: la mayoría de mis proyectos
- github.com/author/simple-lock - unclear, último commit upstream hace 30 días, referenciado en: no estoy seguro
- github.com/author/old-notify - abandoned upstream, último commit upstream hace 500+ días, referenciado en: ninguno
- github.com/author/tiny-scheduler - duplicate, último commit upstream hace 18 días, referenciado en: ninguno (misma función que quick-scheduler)
(los nombres arriba son marcadores de posición, que ilustran la forma de la lista, no las herramientas reales)
Treinta líneas no es nada de leer manualmente. También es suficiente para notar que tienes tres librerías separadas de lógica de reintento haciendo el mismo trabajo, y que uno de los repos del que realmente dependes no ha tenido un commit upstream en más de un año.
La vista de gráfico de la bóveda una vez que existen las 30 notas: cada herramienta como un nodo, los duplicados y los repos de propósito compartido agrupados en clústeres visibles.
Bucle 2: las pasadas que solo funcionan una vez que has recolectado 30+ herramientas
El README de una sola herramienta no puede decirte esto. Solo algo que lea a través de todo lo que has agarrado puede hacerlo.
1TRIGGER: cada 12 horas2PASOS:3 Pasada 1, realmente suspendido:4 marca cualquier repo con estado: in-use pero no referenciado en5 ninguno de tus proyectos durante 30+ días, verifica cruzadamente6 contra tus propios repos para uso real, no suposiciones7 Pasada 2, herramientas duplicadas:8 compara "qué hace realmente" en todas las notas, agrupa cualquier9 cosa que resuelva el mismo problema, confirmado por nombres de10 función coincidentes o propósito coincidente, no solo descripciones11 que suenan similares12 Pasada 3, riesgo upstream:13 marca cualquier herramienta de la que dependas cuyo último commit14 upstream tenga 120+ días de antigüedad, para que sepas qué15 dependencias podrían volverse obsoletas sin previo aviso16 Pasada 4, la lectura honesta:17 una línea por herramienta sobre si merece el espacio en disco y18 la carga mental de recordar que existe, sin suavizar19VERIFICAR: cada pasada escribe en memory/PORTFOLIO.md, las agrupaciones20 de la Pasada 2 respaldadas por una función o propósito21 compartido real22PARAR: las cuatro pasadas completadas, o una pasada falla y se23 registra, nunca se salta en silencio
La Pasada 3 es la que realmente cambia cómo trabajas. No te das cuenta de que dependes de tres herramientas cuyos mantenedores se callaron hace un año hasta que está sentado en una lista frente a ti.
Una tabla de riesgo generada a partir de la Pasada 3: herramientas que realmente estás usando, ordenadas por cuánto tiempo ha pasado desde que su proyecto upstream se movió por última vez.
¿Pruebas primero la versión manual?
La misma regla de siempre. No programes nada que no hayas probado a mano.
1Trabajarás en un bucle hasta que la tarea cumpla con el estándar.23TAREA:4Lee cada carpeta de repo en [ruta]. Para cada una, anota qué hace,5por qué la agarraste originalmente, si todavía la estás usando6realmente, y cuánto tiempo ha pasado desde que el proyecto upstream7hizo su último commit. Luego compara entre todos los repos:8encuentra duplicados y cualquier cosa de la que dependas que se haya9quedado en silencio upstream.1011CRITERIOS DE ÉXITO (estrictos, sin aprobaciones suaves):12- cada "duplicate" está respaldado por una función o propósito13 coincidente real, no descripciones que suenan similares14- cada repo "shelved" incluye días desde que lo referenciaste por15 última vez en algún lugar de tus propios proyectos16- el riesgo upstream se basa en fechas de commit reales, no en17 suposiciones1819PROTOCOLO DE BUCLE, repite en cada turno:201. PLANEA - indica el siguiente paso único212. HAZ - produce o mejora la salida223. VERIFICA - califica 1-10 cada criterio, sé brutalmente honesto234. DECIDE - si cada criterio es 8+, imprime "FINAL" y para2425REGLAS:26- Nunca lo des por terminado hasta que cada criterio sea 8+27- No me hagas preguntas, asume algo sensato y continúa2829Comienza. Ejecuta el bucle hasta FINAL.
Si la lista de duplicados o la lista de riesgo upstream te sorprende, merece una programación. Si solo confirma lo que ya sabías, no lo automatices todavía.
¿El orden que realmente funciona?
Haz que el Bucle 1 funcione hasta que cada repo clonado tenga una nota real, no un marcador de posición.
Déjalo reposar una semana o dos. Cada nueva herramienta que agarres recibe una nota automáticamente de ahí en adelante.
Solo entonces activa el Bucle 2. Las pasadas de duplicados y riesgo upstream necesitan suficientes notas para realmente colisionar entre sí.
Programa esto al final, después de haberlo visto funcionar limpio a mano al menos dos veces.
¿Cuánto cuesta?
El Bucle 1 se ejecuta por cada nuevo clon, así que escala con lo que realmente agarres, no con un horario fijo. La mayoría de las semanas son un puñado de llamadas al modelo barato.
El Bucle 2 se ejecuta dos veces al día en 30+ notas. Mueve la Pasada 1 y la Pasada 3 al modelo barato, son búsquedas, no juicios. Mantén la Pasada 2 y la Pasada 4 en Sonnet, ya que detectar un duplicado real y dar una lectura honesta necesitan un modelo que pueda realmente razonar sobre lo que está comparando. Dividido así, dos ejecuciones al día en una colección de 30 repos cuesta menos que el tiempo que pasarías haciendo la misma auditoría a mano una vez.
¿Lo único que hay que recordar?
Un README te dice qué hace una herramienta. Esto te dice cuál de las 30 herramientas que has encontrado estás usando realmente, cuáles se están duplicando silenciosamente entre sí, y cuáles de las que dependes ya no las mantiene nadie.
El valor nunca estuvo en ninguna nota de herramienta individual. Está en el hecho de que nada de lo que has recolectado puede pudrirse en silencio, duplicarse en silencio, o quedarse sin mantenimiento en silencio sin que algo lo escriba donde realmente lo veas.
Construye el Bucle 1 primero. Déjalo funcionar dos o tres semanas antes de tocar el Bucle 2. Las pasadas de duplicados y riesgo upstream son inútiles con cinco repos. Empiezan a pagarse solas en algún punto después de veinte.
Si quieres más desgloses como este, publico uno cada dos días en Telegram y X. Ambos gratis.
Telegram - https://t.me/GipArcAI
