Encontré más de 30 repositorios de GitHub útiles y dejé de perderles la pista (Claude + Obsidian, guía completa)

Estrella un repo, lo clono, lo dejo medio funcionando 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é un README por repo no es suficiente?

Un README te dice para qué lo construyó el autor. No dice nada sobre por qué lo agarraste, si realmente lo estás usando, o si ya tienes otras tres herramientas haciendo exactamente el mismo trabajo.

Esa es la parte que nadie escribe, porque nadie la escribe para repos que no son suyos. Clonas algo útil, lo ejecutas una vez, y el contexto de por qué desaparece en cuanto cierras la terminal. Multiplica eso por 30 repos en la misma carpeta y obtienes un cementerio que temes 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, con una programación, sin que tengas que acordarte de revisar.

¿Con qué terminarás?

Un vault, dos carpetas:

1found-tools-vault/
2├── notes/                  # una nota markdown por cada repo que has agarrado
3│   ├── some-scraper-tool.md
4│   ├── some-telegram-lib.md
5│   └── ...
6└── memory/
7    └── PORTFOLIO.md         # aquí escriben las cuatro pasadas entre repos

Markdown plano en disco. Ábrelo en Obsidian, o hazle cat desde la terminal. Sin base de datos, nada que no puedas leer tú mismo.

¿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, más abajo, a esta carpeta y la configuración está lista. Todo lo que viene después es lo que le dices a Claude que haga dentro de ella.

¿El stack: las mismas tres piezas, solo apuntando al código de otros?

El vault. Una carpeta de Obsidian, una nota por cada herramienta que has 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 trabajo. Un modelo barato lee el repo y su README. Sonnet hace las decisiones: ¿es esto un duplicado de algo que ya agarraste, y realmente vale 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 envíe código, instale dependencias o ejecute nada de la herramienta en sí. Solo lectura, siempre.
• why_i_grabbed_it se llena a partir de tus propias notas, commits o uso en otros lugares de tus proyectos, no se adivina desde el README del repo.
• Si no puedes determinar si estás usando una herramienta, escribe la nota con status: unclear en lugar de saltártela.

1TRIGGER:   nuevo repo clonado en la carpeta, o una vez al día
2PASOS:
3  1. Lee el repo: README, package.json / requirements.txt, fecha
4     del último commit ascendente, y verifica si está referenciado
5     en 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 | unclear
14       ---
15       ## Qué hace realmente
16       ## Por qué lo agarré
17       ## Si realmente lo estoy usando
18VERIFICAR: cada campo llenado, "referenced_in_my_projects" verificado
19           contra uso real, no asumido
20DETENER:   verificación superada, 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 lees 30 de estos seguidos, la mitad te sorprenderán, ya sea porque olvidaste que estabas usando la herramienta, o porque nunca lo hiciste.

Una nota de herramienta generada, junto a 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 - en uso, último commit ascendente hace 2 días, referenciado en: proyecto feed-reader
• github.com/author/tg-bot-kit - en uso, último commit ascendente hace 5 días, referenciado en: dos de mis bots
• github.com/author/quick-scheduler - archivado, último commit ascendente hace 41 días, referenciado en: ninguno
• github.com/author/api-wrapper-x - en uso, último commit ascendente hace 1 día, referenciado en: un proyecto
• github.com/author/rss-to-json - duplicado, último commit ascendente hace 3 días, referenciado en: ninguno (misma función que scrape-lite)
• github.com/author/cheap-queue - en uso, último commit ascendente hace 6 horas, referenciado en: dos proyectos
• github.com/author/webhook-relay-lib - archivado, último commit ascendente hace 96 días, referenciado en: ninguno
• github.com/author/simple-cache - en uso, último commit ascendente hace 2 días, referenciado en: tres proyectos
• github.com/author/old-scraper - abandonado ascendente, último commit ascendente hace 340 días, referenciado en: ninguno
• github.com/author/notify-me - no claro, último commit ascendente hace 12 días, referenciado en: no estoy seguro
• github.com/author/token-utils - en uso, último commit ascendente hace 1 día, referenciado en: un proyecto
• github.com/author/quick-parser - duplicado, último commit ascendente hace 8 días, referenciado en: ninguno (misma función que rss-to-json)
• github.com/author/tiny-orm - archivado, último commit ascendente hace 55 días, referenciado en: ninguno
• github.com/author/rate-limiter - en uso, último commit ascendente hace 3 días, referenciado en: dos proyectos
• github.com/author/config-loader - en uso, último commit ascendente hace 4 días, referenciado en: la mayoría de mis proyectos
• github.com/author/legacy-fetch - abandonado ascendente, último commit ascendente hace 400+ días, referenciado en: ninguno
• github.com/author/env-check - en uso, último commit ascendente hace 9 días, referenciado en: un proyecto
• github.com/author/pretty-logs - archivado, último commit ascendente hace 70 días, referenciado en: ninguno
• github.com/author/proxy-list - no claro, último commit ascendente hace 20 días, referenciado en: no estoy seguro
• github.com/author/backoff-lib - en uso, último commit ascendente hace 6 días, referenciado en: dos proyectos
• github.com/author/dead-simple-db - archivado, último commit ascendente hace 88 días, referenciado en: ninguno
• github.com/author/quick-hash - en uso, último commit ascendente hace 1 día, referenciado en: un proyecto
• github.com/author/retry-wrapper - duplicado, último commit ascendente hace 14 días, referenciado en: ninguno (misma función que backoff-lib)
• github.com/author/format-time - en uso, último commit ascendente hace 2 días, referenciado en: la mayoría de mis proyectos
• github.com/author/quick-mailer - archivado, último commit ascendente hace 50 días, referenciado en: ninguno
• github.com/author/health-check-lib - en uso, último commit ascendente hace 5 días, referenciado en: dos proyectos
• github.com/author/dotenv-plus - en uso, último commit ascendente hace 3 días, referenciado en: la mayoría de mis proyectos
• github.com/author/simple-lock - no claro, último commit ascendente hace 30 días, referenciado en: no estoy seguro
• github.com/author/old-notify - abandonado ascendente, último commit ascendente hace 500+ días, referenciado en: ninguno
• github.com/author/tiny-scheduler - duplicado, último commit ascendente hace 18 días, referenciado en: ninguno (misma función que quick-scheduler)

(los nombres de 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 bibliotecas de lógica de reintento separadas haciendo el mismo trabajo, y que uno de los repos del que realmente dependes no ha tenido un commit ascendente en más de un año.

La vista de grafo del vault una vez que existen las 30 notas: cada herramienta como un nodo, los duplicados y los repos con 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 horas
2PASOS:
3  Pasada 1, realmente archivado:
4    marca cualquier repo con status: in-use pero no referenciado en
5    ninguno de tus proyectos por 30+ días, verifica contra tus propios
6    repos para uso real, no suposiciones
7  Pasada 2, herramientas duplicadas:
8    compara "qué hace realmente" en todas las notas, agrupa cualquier
9    cosa que resuelva el mismo problema, confirmado por nombres de
10    función coincidentes o propósito coincidente, no solo descripciones
11    que suenan similares
12  Pasada 3, riesgo ascendente:
13    marca cualquier herramienta de la que dependas donde el último
14    commit ascendente tenga 120+ días, para que sepas qué dependencias
15    podrían volverse obsoletas sin previo aviso
16  Pasada 4, la lectura honesta:
17    una línea por herramienta sobre si vale el espacio en disco y la
18    carga mental de recordar que existe, sin suavizar
19VERIFICAR: cada pasada escribe en memory/PORTFOLIO.md, los agrupamientos
20           de la Pasada 2 respaldados por una función o propósito
21           compartido real
22DETENER:  las cuatro pasadas completadas, o una pasada falla y se registra,
23          nunca se omite 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 quedaron en silencio hace un año hasta que está en una lista frente a ti.

Una tabla de riesgos generada a partir de la Pasada 3: herramientas que realmente estás usando, ordenadas por cuánto tiempo ha pasado desde que el proyecto ascendente se movió por última vez.

¿Probar la versión manual primero?

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.
2
3TAREA:
4Lee cada carpeta de repo en [ruta]. Para cada uno, anota qué hace,
5por qué lo agarraste originalmente, si todavía lo estás usando
6realmente, y cuánto tiempo ha pasado desde el último commit del
7proyecto ascendente. Luego compara entre todos los repos: encuentra
8duplicados y cualquier cosa de la que dependas que se haya quedado
9en silencio ascendente.
10
11CRITERIOS DE ÉXITO (estrictos, sin aprobaciones suaves):
12- cada "duplicado" está respaldado por una función o propósito
13  coincidente real, no descripciones que suenan similares
14- cada repo "archivado" incluye días desde que lo referenciaste por
15  última vez en tus propios proyectos
16- el riesgo ascendente se basa en fechas de commit reales, no suposiciones
17
18PROTOCOLO DE BUCLE, repite cada turno:
191. PLANEA   - indica el siguiente paso único
202. HAZ      - produce o mejora la salida
213. VERIFICA - puntúa 1-10 en cada criterio, sé brutalmente honesto
224. DECIDE   - si cada criterio es 8+, imprime "FINAL" y detente
23
24REGLAS:
25- Nunca lo des por terminado hasta que cada criterio sea 8+
26- No me hagas preguntas, asume algo sensato y continúa
27
28Comienza. Ejecuta el bucle hasta FINAL.

Si la lista de duplicados o la lista de riesgo ascendente 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 o dos semanas. Cada nueva herramienta que agarres obtiene una nota automáticamente a partir de ahí.

Solo entonces activa el Bucle 2. Las pasadas de duplicados y riesgo ascendente necesitan suficientes notas para realmente chocar entre sí.

Programalo al final, después de haberlo visto funcionar limpio a mano al menos dos veces.

¿Qué cuesta?

El Bucle 1 se ejecuta por cada nuevo clon, por lo que escala con lo que realmente agarras, no con una programación fija. 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 más de 30 notas. Mueve la Pasada 1 y la Pasada 3 al modelo barato, son búsquedas, no decisiones. 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 realmente pueda razonar sobre lo que está comparando. Dividido de esa manera, dos ejecuciones al día en una colección de 30 repos cuesta menos que el tiempo que dedicarías a hacer la misma auditoría a mano una vez.

Lo único 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 estás usando que ya nadie mantiene.

El valor nunca estuvo en ninguna nota de herramienta individual. Está en el hecho de que nada de lo que has recolectado puede pudrirse, duplicarse o quedar 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 ascendente son inútiles con cinco repos. Empiezan a pagarse por sí mismas en algún lugar después de veinte.

Si quieres más desgloses como este, publico uno cada dos días en Telegram y X. Ambos gratis.

X - https://x.com/gippp69

Telegram - https://t.me/GipArcAI