Я знайшов 30+ корисних репозиторіїв GitHub і перестав їх губити (Claude + Obsidian, повний посібник)

Я зберігаю репозиторій, клоную його, доводжу до напівпрацездатного стану й переходжу до наступної задачі. Через три місяці я знову знаходжу ту саму теку й не можу згадати, навіщо я її забирав, чи я взагалі її використовував, чи, можливо, я клонував один і той самий інструмент двічі під різними назвами. Коли репозиторіїв стає понад 30, це перестає бути жартом і починає коштувати реального часу.

Чому README на репозиторій не вистачає?

README розповідає, для чого автор створив цей інструмент. Він нічого не каже про те, чому саме ви його забрали, чи ви його насправді використовуєте, чи у вас уже є три інші інструменти, які роблять те саме.

Ось та частина, яку ніхто не записує, бо ніхто не записує її для чужих репозиторіїв. Ви клонуєте щось корисне, запускаєте один раз, і контекст того, навіщо ви це робили, зникає, щойно ви закриваєте термінал. Помножте це на 30 репозиторіїв, що лежать в одній теці, і отримаєте цвинтар, який ви боїтеся прибирати, бо не знаєте, що є важливим, а що — мертвим вантажем.

Жодна з цієї інформації не з'являється в жодному окремому README. Вона з'являється лише тоді, коли щось читає все, що ви зібрали, за розкладом, без необхідності вам пам'ятати про це перевіряти.

Що ви отримаєте в результаті?

Одне сховище, дві теки:

1found-tools-vault/
2├── notes/                  # один файл нотаток у форматі markdown на кожен завантажений репозиторій
3│   ├── some-scraper-tool.md
4│   ├── some-telegram-lib.md
5│   └── ...
6└── memory/
7    └── PORTFOLIO.md         # сюди записуються результати чотирьох крос-репозиторних проходів

Звичайний markdown на диску. Відкривайте його в Obsidian, або читайте через cat у терміналі. Жодної бази даних, нічого, що ви не змогли б прочитати самі.

Як це налаштувати?

На Mac або Linux:

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

На Windows, PowerShell:

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

Спрямуйте Цикл 1 та Цикл 2, описані нижче, на цю теку, і налаштування завершено. Все, що далі — це те, що ви доручаєте Claude робити всередині.

Стек: ті самі три компоненти, просто спрямовані на чужий код?

Сховище. Одна тека Obsidian, одна нотатка на кожен клонований інструмент, плюс тека для крос-репозиторних проходів.

Джерело. Кожен репозиторій, що лежить у вашій теці для клонів, незалежно від того, чи користуєтеся ви ним щодня, чи забули про його існування.

Мозок. Claude, розділений за завданнями. Дешева модель читає репозиторій та його README. Sonnet виконує оціночні судження: чи це дублікат чогось, що ви вже забирали, і чи він дійсно вартий місця на диску.

Цикл 1: одна нотатка на інструмент, написана Claude, а не вами?

Важливо, перш ніж запускати це на чомусь реальному:

• Ніколи не дозволяйте цьому циклу надсилати код, встановлювати залежності або запускати що-небудь із самого інструменту. Завжди лише читання.
• why_i_grabbed_it заповнюється з ваших власних нотаток, комітів або використання в інших ваших проєктах, а не вгадується з README самого репозиторію.
• Якщо ви не можете визначити, чи використовуєте ви інструмент, напишіть нотатку зі статусом: unclear, а не пропускайте його.

1TRIGGER:   новий репозиторій клоновано в теку, або раз на день
2КРОКИ:
3  1. Прочитати репозиторій: README, package.json / requirements.txt, дату
4     останнього коміту в апстрімі, та перевірити, чи посилається на нього
5     щось у ваших інших проєктах (імпорти, конфіги, скрипти)
6  2. Написати або оновити notes/<назва-репозиторію>.md із:
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       ## Що він насправді робить
16       ## Чому я його забрав
17       ## Чи я насправді його використовую
18ПЕРЕВІРКА:    всі поля заповнені, "referenced_in_my_projects" перевірено
19              на основі реального використання, а не припущень
20ЗУПИНКА:      перевірка пройдена, або 2 повторні спроби, потім позначити для ручного огляду

Одне це варто створити, навіть без Циклу 2. Перший раз, коли ви прочитаєте 30 таких нотаток поспіль, половина з них вас здивує — або тому, що ви забули, що використовуєте інструмент, або тому, що ніколи його не використовували.

Одна згенерована нотатка про інструмент, поруч із реальною клонованою текою, яку вона описує. Це контекст, який ви інакше ніколи б не записали.

Як виглядають 30 знайдених репозиторіїв після запуску Циклу 1?

Список, який Claude перегенеровує щоразу, коли ви клонуєте щось нове, взятий безпосередньо з нотаток:

• github.com/author/scrape-lite - in-use, last upstream commit 2 days ago, referenced in: feed-reader project
• github.com/author/tg-bot-kit - in-use, last upstream commit 5 days ago, referenced in: two of my bots
• github.com/author/quick-scheduler - shelved, last upstream commit 41 days ago, referenced in: none
• github.com/author/api-wrapper-x - in-use, last upstream commit 1 day ago, referenced in: one project
• github.com/author/rss-to-json - duplicate, last upstream commit 3 days ago, referenced in: none (same job as scrape-lite)
• github.com/author/cheap-queue - in-use, last upstream commit 6 hours ago, referenced in: two projects
• github.com/author/webhook-relay-lib - shelved, last upstream commit 96 days ago, referenced in: none
• github.com/author/simple-cache - in-use, last upstream commit 2 days ago, referenced in: three projects
• github.com/author/old-scraper - abandoned upstream, last upstream commit 340 days ago, referenced in: none
• github.com/author/notify-me - unclear, last upstream commit 12 days ago, referenced in: not sure
• github.com/author/token-utils - in-use, last upstream commit 1 day ago, referenced in: one project
• github.com/author/quick-parser - duplicate, last upstream commit 8 days ago, referenced in: none (same job as rss-to-json)
• github.com/author/tiny-orm - shelved, last upstream commit 55 days ago, referenced in: none
• github.com/author/rate-limiter - in-use, last upstream commit 3 days ago, referenced in: two projects
• github.com/author/config-loader - in-use, last upstream commit 4 days ago, referenced in: most of my projects
• github.com/author/legacy-fetch - abandoned upstream, last upstream commit 400+ days ago, referenced in: none
• github.com/author/env-check - in-use, last upstream commit 9 days ago, referenced in: one project
• github.com/author/pretty-logs - shelved, last upstream commit 70 days ago, referenced in: none
• github.com/author/proxy-list - unclear, last upstream commit 20 days ago, referenced in: not sure
• github.com/author/backoff-lib - in-use, last upstream commit 6 days ago, referenced in: two projects
• github.com/author/dead-simple-db - shelved, last upstream commit 88 days ago, referenced in: none
• github.com/author/quick-hash - in-use, last upstream commit 1 day ago, referenced in: one project
• github.com/author/retry-wrapper - duplicate, last upstream commit 14 days ago, referenced in: none (same job as backoff-lib)
• github.com/author/format-time - in-use, last upstream commit 2 days ago, referenced in: most of my projects
• github.com/author/quick-mailer - shelved, last upstream commit 50 days ago, referenced in: none
• github.com/author/health-check-lib - in-use, last upstream commit 5 days ago, referenced in: two projects
• github.com/author/dotenv-plus - in-use, last upstream commit 3 days ago, referenced in: most of my projects
• github.com/author/simple-lock - unclear, last upstream commit 30 days ago, referenced in: not sure
• github.com/author/old-notify - abandoned upstream, last upstream commit 500+ days ago, referenced in: none
• github.com/author/tiny-scheduler - duplicate, last upstream commit 18 days ago, referenced in: none (same job as quick-scheduler)

(назви вище є заповнювачами, що ілюструють форму списку, а не реальні інструменти)

Тридцять рядків нічого не варто прочитати вручну. Але цього також достатньо, щоб помітити, що у вас є три окремі бібліотеки для логіки повторних спроб, які роблять те саме, і що один із репозиторіїв, від якого ви насправді залежите, не мав комітів в апстрімі вже понад рік.

Вигляд графа сховища, коли всі 30 нотаток існують: кожен інструмент — це вузол, дублікати та репозиторії спільного призначення згруповані у видимі кластери.

Цикл 2: проходи, які працюють лише після того, як ви зібрали 30+ інструментів?

README одного інструменту не може вам цього розповісти. Це може зробити лише те, що читає все, що ви зібрали.

1ТРИГЕР:   кожні 12 годин
2КРОКИ:
3  Прохід 1, реально відкладені на полицю:
4    позначити будь-який репозиторій зі статусом: in-use, але на який
5    немає посилань у жодному з ваших проєктів протягом 30+ днів,
6    перевірити за вашими власними репозиторіями на предмет реального
7    використання, а не припущень
8  Прохід 2, інструменти-дублікати:
9    порівняти "що він насправді робить" у всіх нотатках, згрупувати
10    все, що вирішує одну й ту саму проблему, підтверджено співпадінням
11    назв функцій або співпадінням призначення, а не лише схожими описами
12  Прохід 3, ризик апстріму:
13    позначити будь-який інструмент, від якого ви залежите, де дата
14    останнього коміту в апстрімі становить 120+ днів, щоб ви знали,
15    які залежності можуть застаріти без попередження
16  Прохід 4, чесний аналіз:
17    один рядок на інструмент про те, чи виправдовує він місце на диску
18    та розумове навантаження щодо запам'ятовування його існування,
19    без пом'якшень
20ПЕРЕВІРКА:    кожен прохід записує до memory/PORTFOLIO.md, угруповання
21              Проходу 2 підкріплені реальним співпадінням функцій або призначення
22ЗУПИНКА:      всі чотири проходи завершені, або прохід не вдався і
23              був залогований, ніколи не пропускати мовчки

Прохід 3 — це той, який насправді змінює вашу роботу. Ви не усвідомлюєте, що залежите від трьох інструментів, чиї супровідники замовкли рік тому, поки це не опиниться перед вами у вигляді списку.

Таблиця ризиків, згенерована з Проходу 3: інструменти, які ви насправді використовуєте, відсортовані за часом з моменту останньої активності в їхньому апстрім-проєкті.

Спробувати ручну версію спочатку?

Те саме правило, що й завжди. Не плануйте нічого, що ви не перевірили вручну.

1Ви будете працювати в циклі, доки завдання не відповідатиме критеріям.
2
3ЗАВДАННЯ:
4Прочитати кожну теку репозиторію в [шлях]. Для кожної занотувати, що вона робить,
5чому ви спочатку її забрали, чи ви досі її використовуєте, і скільки часу
6минуло з моменту останнього коміту в апстрім-проєкті. Потім порівняти
7всі репозиторії: знайти дублікати та все, від чого ви залежите, що
8замовкло в апстрімі.
9
10КРИТЕРІЇ УСПІХУ (суворі, без м'яких проходів):
11- кожен "дублікат" підкріплений реальним співпадінням функцій або
12  призначення, а не схожими описами
13- кожен "відкладений" репозиторій включає кількість днів з моменту
14  останнього посилання на нього десь у ваших власних проєктах
15- ризик апстріму базується на реальних датах комітів, а не на припущеннях
16
17ПРОТОКОЛ ЦИКЛУ, повторювати на кожному кроці:
181. ПЛАН   - визначити єдиний наступний крок
192. ДІЯ    - створити або покращити результат
203. ПЕРЕВІРКА - оцінити 1-10 за кожним критерієм, бути нещадно чесним
214. РІШЕННЯ - якщо кожен критерій 8+, вивести "FINAL" і зупинитися
22
23ПРАВИЛА:
24- Ніколи не вважати завдання виконаним, доки кожен критерій не буде 8+
25- Не ставте мені запитань, зробіть розумне припущення та продовжуйте
26
27Почніть. Запустіть цикл до FINAL.

Якщо список дублікатів або список ризику апстріму вас здивує, він заслуговує на планування. Якщо він просто підтверджує те, що ви вже знали, поки що не автоматизуйте його.

Порядок, який насправді працює?

Запустіть Цикл 1, доки кожен клонований репозиторій не матиме справжньої нотатки, а не заповнювача.

Дайте йому постояти тиждень або два. Кожен новий інструмент, який ви забираєте, з цього моменту автоматично отримує нотатку.

Лише потім вмикайте Цикл 2. Проходам для дублікатів і ризику апстріму потрібно достатньо нотаток, щоб насправді стикатися одна з одною.

Плануйте це в останню чергу, після того, як побачите, що він чисто пропрацював вручну принаймні двічі.

Скільки це коштує?

Цикл 1 запускається на кожен новий клон, тому він масштабується залежно від того, скільки ви насправді забираєте, а не за фіксованим розкладом. Більшість тижнів це кілька викликів дешевої моделі.

Цикл 2 запускається двічі на день для 30+ нотаток. Перемістіть Прохід 1 і Прохід 3 на дешеву модель — це пошук, а не оціночні судження. Залиште Прохід 2 і Прохід 4 на Sonnet, оскільки виявлення справжнього дубліката та чесний аналіз потребують моделі, яка може насправді міркувати про те, що вона порівнює. При такому розподілі два запуски на день для колекції з 30 репозиторіїв коштують менше, ніж час, який ви витратили б на той самий аудит вручну один раз.

Єдине, що варто пам'ятати?

README розповідає вам, що робить інструмент. Це розповідає вам, які з 30 знайдених інструментів ви насправді використовуєте, які з них тихо дублюють один одного, і які з них залежать від того, що ніхто більше не підтримує.

Цінність ніколи не була в жодній окремій нотатці про інструмент. Вона в тому, що ніщо з того, що ви зібрали, не може тихо зіпсуватися, тихо продублюватися або тихо залишитися без підтримки, не маючи чогось, що записує це там, де ви насправді це побачите.

Спочатку створіть Цикл 1. Дайте йому попрацювати два-три тижні, перш ніж торкатися Циклу 2. Проходи для дублікатів і ризику апстріму марні з п'ятьма репозиторіями. Вони починають окупатися десь після двадцяти.

Якщо вам потрібно більше подібних розборів, я публікую їх кожні пару днів у Telegram та X. Обидва безкоштовні.

X - https://x.com/gippp69

Telegram - https://t.me/GipArcAI