Encontrei mais de 30 repositórios úteis no GitHub e parei de perdê-los de vista (Claude + Obsidian, Guia Completo)

Eu marco um repositório com estrela, clono ele, deixo funcionando pela metade e passo para o próximo problema. Três meses depois encontro a mesma pasta de novo e não consigo lembrar por que peguei, se realmente usei ou se clonei a mesma ferramenta duas vezes com nomes diferentes. Com mais de trinta repositórios, isso deixa de ser piada e começa a custar tempo de verdade.

Por que um README por repositório não é suficiente?

Um README diz para que o autor construiu aquilo. Não diz nada sobre por que você pegou, se está realmente usando ou se já tem outras três ferramentas fazendo exatamente o mesmo trabalho.

Essa é a parte que ninguém escreve, porque ninguém escreve para repositórios que não são seus. Você clona algo útil, faz funcionar uma vez, e o contexto do porquê desaparece no momento em que fecha o terminal. Multiplique isso por 30 repositórios na mesma pasta e você terá um cemitério que dá medo de limpar, porque não sabe o que é essencial e o que é peso morto.

Nada disso aparece em um único README. Só aparece quando algo lê através de tudo que você colecionou, em uma programação, sem você precisar lembrar de verificar.

O que você vai ter no final?

Um vault, duas pastas:

1found-tools-vault/
2├── notes/                  # uma nota markdown por repositório que você pegou
3│   ├── some-scraper-tool.md
4│   ├── some-telegram-lib.md
5│   └── ...
6└── memory/
7    └── PORTFOLIO.md         # as quatro varreduras entre repositórios escrevem aqui

Markdown puro no disco. Abra no Obsidian, ou leia com cat no terminal. Sem banco de dados, nada que você não possa ler sozinho.

Como configurar?

No Mac ou Linux:

1mkdir -p ~/found-tools-vault/notes ~/found-tools-vault/memory

No Windows, PowerShell:

1New-Item -ItemType Directory -Force -Path "$HOME\found-tools-vault\notes","$HOME\found-tools-vault\memory"

Aponte o Loop 1 e o Loop 2, abaixo, para esta pasta e a configuração está pronta. Tudo daqui para frente é o que você diz ao Claude para fazer dentro dela.

A stack: as mesmas três peças, só que apontadas para o código dos outros?

O vault. Uma pasta do Obsidian, uma nota por ferramenta que você clonou, mais uma pasta para varreduras entre repositórios.

A fonte. Cada repositório na sua pasta de clones, seja usado diariamente ou esquecido.

O cérebro. O Claude, dividido por tarefa. Um modelo barato lê o repositório e seu README. O Sonnet faz os julgamentos: é uma duplicata de algo que você já pegou, e realmente vale o espaço em disco?

Loop 1: uma nota por ferramenta, escrita pelo Claude, não por você?

Importante, antes de executar isso em algo real:

• Nunca deixe este loop enviar código, instalar dependências ou executar qualquer coisa da própria ferramenta. Somente leitura, sempre.
• O campo "why_i_grabbed_it" é preenchido a partir de suas próprias anotações, commits ou uso em outros projetos, não adivinhado pelo README do repositório.
• Se você não conseguir dizer se está usando uma ferramenta, escreva a nota com status: unclear em vez de pular.

1TRIGGER:   novo repositório clonado na pasta, ou uma vez ao dia
2PASSOS:
3  1. Leia o repositório: README, package.json / requirements.txt, data
4     do último commit upstream, e verifique se é referenciado em algum
5     lugar nos seus outros projetos (imports, configs, scripts)
6  2. Escreva ou atualize notes/<nome-do-repo>.md com:
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       ## O que realmente faz
16       ## Por que peguei
17       ## Estou realmente usando
18VERIFICAR:  todos os campos preenchidos, "referenced_in_my_projects" verificado
19            contra uso real, não suposições
20PARAR:      verificação passa, ou 2 tentativas, então sinalizar para revisão manual

Só isso já vale a pena construir mesmo sem o Loop 2. Na primeira vez que você ler 30 dessas notas em sequência, metade vai te surpreender, seja porque esqueceu que estava usando a ferramenta, ou porque nunca usou.

Uma nota de ferramenta gerada, ao lado da pasta clonada real que ela descreve. Este é o contexto que você nunca escreveria.

Como ficam 30 repositórios encontrados depois que o Loop 1 roda?

Uma lista que o Claude regenera toda vez que você clona algo novo, puxada diretamente das notas:

• github.com/author/scrape-lite - em uso, último commit upstream há 2 dias, referenciado em: projeto feed-reader
• github.com/author/tg-bot-kit - em uso, último commit upstream há 5 dias, referenciado em: dois dos meus bots
• github.com/author/quick-scheduler - arquivado, último commit upstream há 41 dias, referenciado em: nenhum
• github.com/author/api-wrapper-x - em uso, último commit upstream há 1 dia, referenciado em: um projeto
• github.com/author/rss-to-json - duplicata, último commit upstream há 3 dias, referenciado em: nenhum (mesmo trabalho que scrape-lite)
• github.com/author/cheap-queue - em uso, último commit upstream há 6 horas, referenciado em: dois projetos
• github.com/author/webhook-relay-lib - arquivado, último commit upstream há 96 dias, referenciado em: nenhum
• github.com/author/simple-cache - em uso, último commit upstream há 2 dias, referenciado em: três projetos
• github.com/author/old-scraper - abandonado upstream, último commit upstream há 340 dias, referenciado em: nenhum
• github.com/author/notify-me - incerto, último commit upstream há 12 dias, referenciado em: não tenho certeza
• github.com/author/token-utils - em uso, último commit upstream há 1 dia, referenciado em: um projeto
• github.com/author/quick-parser - duplicata, último commit upstream há 8 dias, referenciado em: nenhum (mesmo trabalho que rss-to-json)
• github.com/author/tiny-orm - arquivado, último commit upstream há 55 dias, referenciado em: nenhum
• github.com/author/rate-limiter - em uso, último commit upstream há 3 dias, referenciado em: dois projetos
• github.com/author/config-loader - em uso, último commit upstream há 4 dias, referenciado em: a maioria dos meus projetos
• github.com/author/legacy-fetch - abandonado upstream, último commit upstream há 400+ dias, referenciado em: nenhum
• github.com/author/env-check - em uso, último commit upstream há 9 dias, referenciado em: um projeto
• github.com/author/pretty-logs - arquivado, último commit upstream há 70 dias, referenciado em: nenhum
• github.com/author/proxy-list - incerto, último commit upstream há 20 dias, referenciado em: não tenho certeza
• github.com/author/backoff-lib - em uso, último commit upstream há 6 dias, referenciado em: dois projetos
• github.com/author/dead-simple-db - arquivado, último commit upstream há 88 dias, referenciado em: nenhum
• github.com/author/quick-hash - em uso, último commit upstream há 1 dia, referenciado em: um projeto
• github.com/author/retry-wrapper - duplicata, último commit upstream há 14 dias, referenciado em: nenhum (mesmo trabalho que backoff-lib)
• github.com/author/format-time - em uso, último commit upstream há 2 dias, referenciado em: a maioria dos meus projetos
• github.com/author/quick-mailer - arquivado, último commit upstream há 50 dias, referenciado em: nenhum
• github.com/author/health-check-lib - em uso, último commit upstream há 5 dias, referenciado em: dois projetos
• github.com/author/dotenv-plus - em uso, último commit upstream há 3 dias, referenciado em: a maioria dos meus projetos
• github.com/author/simple-lock - incerto, último commit upstream há 30 dias, referenciado em: não tenho certeza
• github.com/author/old-notify - abandonado upstream, último commit upstream há 500+ dias, referenciado em: nenhum
• github.com/author/tiny-scheduler - duplicata, último commit upstream há 18 dias, referenciado em: nenhum (mesmo trabalho que quick-scheduler)

(os nomes acima são placeholders, ilustrando a forma da lista, não as ferramentas reais)

Trinta linhas não é nada para ler manualmente. Também é o suficiente para perceber que você tem três bibliotecas de lógica de retry separadas fazendo o mesmo trabalho, e um dos repositórios dos quais você realmente depende não recebe um commit upstream há mais de um ano.

A visualização em grafo do vault quando todas as 30 notas existem: cada ferramenta como um nó, as duplicatas e repositórios com propósito compartilhado agrupados em clusters visíveis.

Loop 2: as varreduras que só funcionam depois que você colecionou 30+ ferramentas?

O README de uma única ferramenta não pode te dizer isso. Só algo que lê através de tudo que você pegou pode.

1TRIGGER:   a cada 12 horas
2PASSOS:
3  Passo 1, realmente arquivado:
4    marque qualquer repositório com status: in-use mas não referenciado em nenhum
5    dos seus projetos por 30+ dias, verifique cruzadamente com seus próprios repositórios
6    para uso real, não suposições
7  Passo 2, ferramentas duplicadas:
8    compare "o que realmente faz" em todas as notas, agrupe qualquer coisa
9    resolvendo o mesmo problema, confirmado por nomes de função correspondentes
10    ou propósito correspondente, não apenas descrições com som similar
11  Passo 3, risco upstream:
12    marque qualquer ferramenta da qual você depende onde o último commit upstream
13    tenha 120+ dias, para que você saiba quais dependências podem ficar
14    obsoletas sem aviso
15  Passo 4, a leitura honesta:
16    uma linha por ferramenta sobre se ela merece o espaço em disco e a
17    sobrecarga mental de lembrar que existe, sem suavizar
18VERIFICAR:  cada passo escreve em memory/PORTFOLIO.md, os agrupamentos do Passo 2
19            apoiados por uma função ou propósito compartilhado real
20PARAR:      todos os quatro passos completos, ou um passo falha e é registrado,
21            nunca pulado silenciosamente

O Passo 3 é o que realmente muda a forma como você trabalha. Você não percebe que depende de três ferramentas cujos mantenedores ficaram quietos há um ano até que isso esteja numa lista na sua frente.

Uma tabela de risco gerada a partir do Passo 3: ferramentas que você está realmente usando, ordenadas por quanto tempo desde que o projeto upstream se mexeu pela última vez.

Que tal testar a versão manual primeiro?

Mesma regra de sempre. Não agende nada que você não tenha provado manualmente.

1Você vai trabalhar em loop até que a tarefa atenda ao padrão.
2
3TAREFA:
4Leia cada pasta de repositório em [caminho]. Para cada um, anote o que faz,
5por que você o pegou originalmente, se ainda está realmente usando,
6e há quanto tempo o projeto upstream fez o último commit. Depois
7compare todos os repositórios: encontre duplicatas e qualquer coisa da qual
8você depende que está parada no upstream.
9
10CRITÉRIOS DE SUCESSO (rigorosos, sem passes fáceis):
11- cada "duplicata" é apoiada por uma função ou propósito real correspondente,
12  não descrições com som similar
13- cada repositório "arquivado" inclui dias desde que você o referenciou pela última vez
14  em qualquer lugar nos seus próprios projetos
15- risco upstream é baseado em datas reais de commit, não suposições
16
17PROTOCOLO DE LOOP, repita a cada turno:
181. PLANEJE   - declare o único próximo passo
192. FAÇA      - produza ou melhore a saída
203. VERIFIQUE - dê uma nota de 1 a 10 em cada critério, seja brutalmente honesto
214. DECIDA    - se todo critério é 8+, imprima "FINAL" e pare
22
23REGRAS:
24- Nunca considere pronto até que todo critério seja 8+
25- Não me faça perguntas, assuma algo sensato e continue
26
27Comece. Execute o loop até FINAL.

Se a lista de duplicatas ou a lista de risco upstream te surpreender, ela merece uma agenda. Se apenas confirmar o que você já sabia, não automatize ainda.

A ordem que realmente funciona?

Faça o Loop 1 rodar até que cada repositório clonado tenha uma nota real, não um espaço reservado.

Deixe descansar por uma ou duas semanas. Toda nova ferramenta que você pegar ganha uma nota automaticamente daí em diante.

Só então ligue o Loop 2. As varreduras de duplicatas e risco upstream precisam de notas suficientes para realmente colidirem.

Agende por último, depois de vê-lo rodar limpo manualmente pelo menos duas vezes.

Quanto custa?

O Loop 1 roda por novo clone, então escala com o quanto você realmente pega, não com uma agenda fixa. Na maioria das semanas, são algumas chamadas de modelo barato.

O Loop 2 roda duas vezes ao dia em 30+ notas. Mova o Passo 1 e o Passo 3 para o modelo barato, são consultas, não julgamentos. Mantenha o Passo 2 e o Passo 4 no Sonnet, já que identificar uma duplicata real e dar uma leitura honesta ambos precisam de um modelo que consiga realmente raciocinar sobre o que está comparando. Dividido assim, duas execuções por dia em uma coleção de 30 repositórios custa menos do que o tempo que você gastaria fazendo a mesma auditoria manualmente uma vez.

A única coisa para lembrar?

Um README diz o que uma ferramenta faz. Isso aqui diz quais das 30 ferramentas que você encontrou você está realmente usando, quais estão silenciosamente se duplicando, e quais você está usando que ninguém mais mantém.

O valor nunca esteve em nenhuma nota de ferramenta individual. Está no fato de que nada que você colecionou pode apodrecer silenciosamente, se duplicar silenciosamente, ou ficar sem manutenção silenciosamente sem que algo escreva isso onde você realmente vai ver.

Construa o Loop 1 primeiro. Deixe rodar por duas ou três semanas antes de tocar no Loop 2. As varreduras de duplicatas e risco upstream são inúteis com cinco repositórios. Elas começam a se pagar em algum lugar depois de vinte.

Se quiser mais análises como esta, eu publico uma a cada dois dias no Telegram e no X. Ambos gratuitos.

X - https://x.com/gippp69

Telegram - https://t.me/GipArcAI