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

Eu marco um repositório com estrela, clono ele, faço funcionar 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 baixei, 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ê baixou, 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 de por que fez isso desaparece no momento em que fecha o terminal. Multiplique isso por 30 repositórios na mesma pasta e você terá um cemitério que tem 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 o que você coletou, em uma programação, sem você precisar lembrar de verificar.

O que você vai ter no final?

Um cofre, duas pastas:

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

Markdown simples no disco. Abra no Obsidian, ou use 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 cofre. Uma pasta do Obsidian, uma nota por ferramenta que você clonou, mais uma pasta para as passagens entre repositórios.

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

O cérebro. 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á baixou 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 algo da própria ferramenta. Apenas leitura, sempre.
• O campo why_i_grabbed_it é preenchido a partir de suas próprias anotações, commits ou uso em outros projetos seus, não adivinhado a partir do README do repositório.
• Se você não conseguir dizer se está usando uma ferramenta, escreva a nota com status: unclear em vez de pulá-la.

1TRIGGER:   novo repositório clonado na pasta, ou uma vez ao dia
2PASSOS:
3  1. Leia o repositório: README, package.json / requirements.txt,
4     data do último commit upstream e verifique se é referenciado
5     em algum lugar nos seus outros projetos (imports, configurações, 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 assumido
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 seguidas, metade delas vai te surpreender, seja porque você 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 realmente ficam 30 repositórios encontrados depois que o Loop 1 é executado?

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 (mesma função 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 (mesma função 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 (mesma função 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 (mesma função que quick-scheduler)

(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 cofre assim que todas as 30 notas existem: cada ferramenta como um nó, as duplicatas e repositórios de propósito compartilhado agrupados em clusters visíveis.

Loop 2: as passagens que só funcionam depois que você coletou 30+ ferramentas?

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

1TRIGGER:   a cada 12 horas
2PASSOS:
3  Passagem 1, realmente arquivado:
4    sinalize qualquer repositório com status: in-use mas não referenciado em nenhum
5    dos seus projetos por 30+ dias, verifique em seus próprios repositórios
6    o uso real, não suposições
7  Passagem 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 semelhante
11  Passagem 3, risco upstream:
12    sinalize 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    desatualizadas sem aviso
15  Passagem 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 passagem escreve em memory/PORTFOLIO.md, os agrupamentos da
19              Passagem 2 apoiados por uma função ou propósito compartilhado real
20PARAR:        todas as quatro passagens completas, ou uma passagem falha e é registrada,
21              nunca pulada silenciosamente

A Passagem 3 é a 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 esteja em uma lista na sua frente.

Uma tabela de risco gerada a partir da Passagem 3: ferramentas que você está realmente usando, ordenadas por quanto tempo desde que o projeto upstream foi atualizado pela última vez.

Experimente a versão manual primeiro?

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

1Você vai trabalhar em um 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 baixou originalmente, se ainda está realmente usando
6e há quanto tempo desde o último commit do projeto upstream. Depois
7compare todos os repositórios: encontre duplicatas e qualquer coisa da qual
8você depende que ficou quieta 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 semelhante
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 DO 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 cada critério for 8+, imprima "FINAL" e pare
22
23REGRAS:
24- Nunca considere concluído até que cada critério seja 8+
25- Não me faça perguntas, tome uma suposição sensata 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 programação. Se apenas confirmar o que você já sabia, não automatize ainda.

A ordem que realmente funciona?

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

Deixe descansar por uma ou duas semanas. Cada nova ferramenta que você baixar ganha uma nota automaticamente a partir daí.

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

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

Quanto custa?

O Loop 1 é executado por novo clone, então escala com o quanto você realmente baixa, não com uma programação fixa. Na maioria das semanas, são algumas chamadas de modelo barato.

O Loop 2 é executado duas vezes ao dia em 30+ notas. Mova a Passagem 1 e a Passagem 3 para o modelo barato, são consultas, não julgamentos. Mantenha a Passagem 2 e a Passagem 4 no Sonnet, já que identificar uma duplicata real e fazer uma leitura honesta precisam de um modelo que possa realmente raciocinar sobre o que está comparando. Dividido dessa forma, 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 te diz o que uma ferramenta faz. Isso te 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 uma única nota de ferramenta. Está no fato de que nada que você coletou pode apodrecer silenciosamente, duplicar silenciosamente ou ficar sem manutenção silenciosamente sem que algo escreva isso onde você realmente vai ver.

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

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

X - https://x.com/gippp69

Telegram - https://t.me/GipArcAI