Ich starre ein Repository, klone es, bringe es halb zum Laufen und wende mich dem nächsten Problem zu. Drei Monate später finde ich denselben Ordner wieder und kann mich nicht erinnern, warum ich ihn überhaupt geholt habe, ob ich ihn jemals wirklich benutzt habe oder ob ich dasselbe Tool zweimal unter einem anderen Namen geklont habe. Ab dreißig Repositories hört das auf, ein Witz zu sein, und kostet richtig Zeit.
Warum eine README pro Repository nicht ausreicht?
Eine README sagt dir, wofür der Autor es gebaut hat. Sie sagt nichts darüber, warum du es geholt hast, ob du es tatsächlich nutzt oder ob du bereits drei andere Tools hast, die exakt dieselbe Aufgabe erledigen.
Das ist der Teil, den niemand aufschreibt, weil niemand ihn für Repositories aufschreibt, die nicht seine eigenen sind. Du klonst etwas Nützliches, bringst es einmal zum Laufen, und der Kontext, warum, verschwindet in dem Moment, in dem du das Terminal schließt. Multipliziere das mit 30 Repositories, die im selben Ordner liegen, und du bekommst einen Friedhof, den du dich nicht aufzuräumen traust, weil du nicht sicher bist, was tragend und was totes Gewicht ist.
Nichts davon zeigt sich in einer einzelnen README. Es zeigt sich nur, wenn etwas quer durch alles liest, was du gesammelt hast, regelmäßig, ohne dass du daran denken musst, nachzusehen.
Was am Ende dabei herauskommt?
Ein Vault, zwei Ordner:
1found-tools-vault/2├── notes/ # eine Markdown-Notiz pro geklontem Repository3│ ├── some-scraper-tool.md4│ ├── some-telegram-lib.md5│ └── ...6└── memory/7 └── PORTFOLIO.md # die vier übergreifenden Durchläufe schreiben hier hinein
Reines Markdown auf der Festplatte. Öffne es in Obsidian oder zeige es im Terminal an. Keine Datenbank, nichts, was du nicht selbst lesen kannst.
Einrichtung?
Auf Mac oder Linux:
1mkdir -p ~/found-tools-vault/notes ~/found-tools-vault/memory
Unter Windows, PowerShell:
1New-Item -ItemType Directory -Force -Path "$HOME\found-tools-vault\notes","$HOME\found-tools-vault\memory"
Richte Durchlauf 1 und Durchlauf 2, weiter unten, auf diesen Ordner aus, und die Einrichtung ist abgeschlossen. Alles, was ab hier kommt, sagst du Claude, was es darin tun soll.
Der Stack: dieselben drei Teile, nur auf den Code anderer Leute gerichtet?
Der Vault. Ein Obsidian-Ordner, eine Notiz pro Tool, das du geklont hast, plus ein Ordner für übergreifende Repository-Durchläufe.
Die Quelle. Jedes Repository, das in deinem Klon-Ordner liegt, ob du es täglich nutzt oder vergessen hast, dass es existiert.
Das Gehirn. Claude, aufgeteilt nach Aufgabe. Ein günstiges Modell liest das Repository und seine README. Sonnet übernimmt die Beurteilungen: Ist das ein Duplikat von etwas, das du bereits geholt hast, und ist es den Speicherplatz überhaupt wert?
Durchlauf 1: eine Notiz pro Tool, geschrieben von Claude, nicht von dir?
Wichtig, bevor du das auf irgendetwas Echtes anwendest:
- Lass diesen Durchlauf niemals Code pushen, Abhängigkeiten installieren oder irgendetwas aus dem Tool selbst ausführen. Nur lesender Zugriff, immer.
- Der Grund, warum du es geholt hast, wird aus deinen eigenen Notizen, Commits oder der Nutzung in deinen anderen Projekten ermittelt, nicht aus der README des Repositories selbst geraten.
- Wenn du nicht sagen kannst, ob du ein Tool nutzt, schreibe die Notiz mit dem Status
unklar, anstatt sie auszulassen.
1AUSLÖSER: neues Repository in den Ordner geklont, oder einmal täglich2SCHRITTE:3 1. Lies das Repository: README, package.json / requirements.txt,4 letztes Upstream-Commit-Datum, und prüfe, ob es irgendwo in5 deinen anderen Projekten referenziert wird (Importe, Konfigs,6 Skripte)7 2. Schreibe oder aktualisiere notes/<repo-name>.md mit:8 ---9 repo:10 what_it_does:11 why_i_grabbed_it:12 last_upstream_commit:13 referenced_in_my_projects: []14 status: in-use | shelved | duplicate | unclear15 ---16 ## Was es tatsächlich tut17 ## Warum ich es geholt habe18 ## Nutze ich es tatsächlich?19PRÜFUNG: jedes Feld ausgefüllt, "referenced_in_my_projects" anhand20 der tatsächlichen Nutzung geprüft, nicht angenommen21STOPP: Prüfung bestanden, oder 2 Wiederholungen, dann zur22 manuellen Überprüfung markieren
Das allein ist es wert, es aufzubauen, selbst ohne Durchlauf 2. Wenn du das erste Mal 30 solcher Notizen hintereinander liest, wird dich die Hälfte davon überraschen – entweder weil du vergessen hattest, dass du das Tool nutzt, oder weil du es nie getan hast.
Eine generierte Tool-Notiz, direkt neben dem tatsächlichen geklonten Ordner, den sie beschreibt. Das ist der Kontext, den du sonst nie aufschreiben würdest.
Wie 30 gefundene Repositories tatsächlich aussehen, nachdem Durchlauf 1 gelaufen ist?
Eine Liste, die Claude jedes Mal neu generiert, wenn du etwas Neues klonst, direkt aus den Notizen gezogen:
- github.com/author/scrape-lite – in-use, letztes Upstream-Commit vor 2 Tagen, referenziert in: feed-reader project
- github.com/author/tg-bot-kit – in-use, letztes Upstream-Commit vor 5 Tagen, referenziert in: two of my bots
- github.com/author/quick-scheduler – shelved, letztes Upstream-Commit vor 41 Tagen, referenziert in: none
- github.com/author/api-wrapper-x – in-use, letztes Upstream-Commit vor 1 Tag, referenziert in: one project
- github.com/author/rss-to-json – duplicate, letztes Upstream-Commit vor 3 Tagen, referenziert in: none (gleiche Aufgabe wie scrape-lite)
- github.com/author/cheap-queue – in-use, letztes Upstream-Commit vor 6 Stunden, referenziert in: two projects
- github.com/author/webhook-relay-lib – shelved, letztes Upstream-Commit vor 96 Tagen, referenziert in: none
- github.com/author/simple-cache – in-use, letztes Upstream-Commit vor 2 Tagen, referenziert in: three projects
- github.com/author/old-scraper – abandoned upstream, letztes Upstream-Commit vor 340 Tagen, referenziert in: none
- github.com/author/notify-me – unclear, letztes Upstream-Commit vor 12 Tagen, referenziert in: not sure
- github.com/author/token-utils – in-use, letztes Upstream-Commit vor 1 Tag, referenziert in: one project
- github.com/author/quick-parser – duplicate, letztes Upstream-Commit vor 8 Tagen, referenziert in: none (gleiche Aufgabe wie rss-to-json)
- github.com/author/tiny-orm – shelved, letztes Upstream-Commit vor 55 Tagen, referenziert in: none
- github.com/author/rate-limiter – in-use, letztes Upstream-Commit vor 3 Tagen, referenziert in: two projects
- github.com/author/config-loader – in-use, letztes Upstream-Commit vor 4 Tagen, referenziert in: most of my projects
- github.com/author/legacy-fetch – abandoned upstream, letztes Upstream-Commit vor 400+ Tagen, referenziert in: none
- github.com/author/env-check – in-use, letztes Upstream-Commit vor 9 Tagen, referenziert in: one project
- github.com/author/pretty-logs – shelved, letztes Upstream-Commit vor 70 Tagen, referenziert in: none
- github.com/author/proxy-list – unclear, letztes Upstream-Commit vor 20 Tagen, referenziert in: not sure
- github.com/author/backoff-lib – in-use, letztes Upstream-Commit vor 6 Tagen, referenziert in: two projects
- github.com/author/dead-simple-db – shelved, letztes Upstream-Commit vor 88 Tagen, referenziert in: none
- github.com/author/quick-hash – in-use, letztes Upstream-Commit vor 1 Tag, referenziert in: one project
- github.com/author/retry-wrapper – duplicate, letztes Upstream-Commit vor 14 Tagen, referenziert in: none (gleiche Aufgabe wie backoff-lib)
- github.com/author/format-time – in-use, letztes Upstream-Commit vor 2 Tagen, referenziert in: most of my projects
- github.com/author/quick-mailer – shelved, letztes Upstream-Commit vor 50 Tagen, referenziert in: none
- github.com/author/health-check-lib – in-use, letztes Upstream-Commit vor 5 Tagen, referenziert in: two projects
- github.com/author/dotenv-plus – in-use, letztes Upstream-Commit vor 3 Tagen, referenziert in: most of my projects
- github.com/author/simple-lock – unclear, letztes Upstream-Commit vor 30 Tagen, referenziert in: not sure
- github.com/author/old-notify – abandoned upstream, letztes Upstream-Commit vor 500+ Tagen, referenziert in: none
- github.com/author/tiny-scheduler – duplicate, letztes Upstream-Commit vor 18 Tagen, referenziert in: none (gleiche Aufgabe wie quick-scheduler)
(Die Namen oben sind Platzhalter, die die Form der Liste veranschaulichen, nicht die tatsächlichen Tools)
Dreißig Zeilen sind nichts, was man manuell lesen müsste. Es reicht aber auch aus, um zu bemerken, dass du drei separate Retry-Logic-Bibliotheken hast, die dieselbe Aufgabe erledigen, und dass eines der Repositories, von dem du tatsächlich abhängst, seit über einem Jahr kein Upstream-Commit mehr hatte.
Die Graphenansicht des Vaults, sobald alle 30 Notizen existieren: jedes Tool als Knoten, die Duplikate und Repositories mit gemeinsamem Zweck in sichtbaren Clustern zusammengefasst.
Durchlauf 2: die Durchläufe, die erst funktionieren, wenn du 30+ Tools gesammelt hast?
Die README eines einzelnen Tools kann dir das nicht sagen. Nur etwas, das quer durch alles liest, was du gesammelt hast, kann das.
1AUSLÖSER: alle 12 Stunden2SCHRITTE:3 Durchlauf 1, tatsächlich auf Eis gelegt:4 markiere jedes Repository mit status: in-use, das seit 30+ Tagen5 in keinem deiner Projekte referenziert wird, und gleiche es mit6 deinen eigenen Repositories auf tatsächliche Nutzung ab, nicht7 auf Annahmen8 Durchlauf 2, doppelte Tools:9 vergleiche "was es tatsächlich tut" über alle Notizen hinweg,10 gruppiere alles, was dasselbe Problem löst, bestätigt durch11 übereinstimmende Funktionsnamen oder übereinstimmenden Zweck,12 nicht nur durch ähnlich klingende Beschreibungen13 Durchlauf 3, Upstream-Risiko:14 markiere jedes Tool, von dem du abhängst, bei dem das letzte15 Upstream-Commit 120+ Tage zurückliegt, damit du weißt, welche16 Abhängigkeiten ohne Vorwarnung veralten könnten17 Durchlauf 4, die ehrliche Bestandsaufnahme:18 eine Zeile pro Tool, ob es den Speicherplatz und den mentalen19 Aufwand, sich an seine Existenz zu erinnern, wert ist, ohne20 Beschönigung21PRÜFUNG: jeder Durchlauf schreibt in memory/PORTFOLIO.md, die22 Gruppierungen von Durchlauf 2 sind durch einen tatsächlichen23 gemeinsamen Funktions- oder Zweckabgleich untermauert24STOPP: alle vier Durchläufe abgeschlossen, oder ein Durchlauf25 schlägt fehl und wird protokolliert, niemals stillschweigend26 übersprungen
Durchlauf 3 ist derjenige, der tatsächlich ändert, wie du arbeitest. Du merkst nicht, dass du von drei Tools abhängst, deren Maintainer vor einem Jahr verstummt sind, bis es in einer Liste vor dir liegt.
Eine Risikotabelle, erstellt aus Durchlauf 3: Tools, die du tatsächlich nutzt, sortiert danach, wie lange seit der letzten Aktivität ihres Upstream-Projekts vergangen ist.
Zuerst die manuelle Version ausprobieren?
Die gleiche Regel wie immer. Plane nichts ein, was du nicht von Hand nachgewiesen hast.
1You will work in a loop until the task meets the bar.23TASK:4Read every repo folder in [path]. For each one, note what it does,5why you originally grabbed it, whether you're still actually using6it, and how long since the upstream project last committed. Then7compare across all repos: find duplicates and anything you depend8on that's gone quiet upstream.910SUCCESS CRITERIA (strict, no soft passes):11- every "duplicate" is backed by an actual matching function or12 purpose, not similar-sounding descriptions13- every "shelved" repo includes days since you last referenced it14 anywhere in your own projects15- upstream risk is based on real commit dates, not assumptions1617LOOP PROTOCOL, repeat every turn:181. PLAN - state the single next step192. DO - produce or improve the output203. VERIFY - score 1-10 on each criterion, be brutally honest214. DECIDE - if every criterion is 8+, print "FINAL" and stop2223RULES:24- Never call it done until every criterion is 8+25- Do not ask me questions, make a sensible assumption and continue2627Begin. Run the loop until FINAL.
Wenn dich die Duplikatliste oder die Upstream-Risiko-Liste überrascht, hat sie einen Zeitplan verdient. Wenn sie nur bestätigt, was du bereits wusstest, automatisiere sie noch nicht.
Die Reihenfolge, die tatsächlich funktioniert?
Bringe Durchlauf 1 zum Laufen, bis jedes geklonte Repository eine echte Notiz hat, keinen Platzhalter.
Lass es ein oder zwei Wochen ruhen. Jedes neue Tool, das du holst, bekommt von da an automatisch eine Notiz.
Schalte erst dann Durchlauf 2 ein. Die Duplikat- und Upstream-Risiko-Durchläufe brauchen genügend Notizen, um tatsächlich aufeinanderzutreffen.
Plane es als Letztes ein, nachdem du gesehen hast, dass es von Hand mindestens zweimal sauber läuft.
Was kostet es?
Durchlauf 1 läuft pro neuem Klon, skaliert also mit dem, was du tatsächlich holst, nicht mit einem festen Zeitplan. In den meisten Wochen sind das ein paar Aufrufe des günstigen Modells.
Durchlauf 2 läuft zweimal täglich über 30+ Notizen. Verlege Durchlauf 1 und Durchlauf 3 auf das günstige Modell – es sind Nachschlagevorgänge, keine Beurteilungen. Behalte Durchlauf 2 und Durchlauf 4 auf Sonnet, da das Erkennen eines echten Duplikats und das Geben einer ehrlichen Einschätzung ein Modell erfordern, das tatsächlich über das nachdenken kann, was es vergleicht. So aufgeteilt kosten zwei Läufe pro Tag über eine Sammlung von 30 Repositories weniger als die Zeit, die du für dieselbe Überprüfung von Hand einmal aufwenden würdest.
Das Einzige, woran du denken solltest?
Eine README sagt dir, was ein Tool tut. Dieses System sagt dir, welche der 30 Tools, die du gefunden hast, du tatsächlich nutzt, welche sich still und leise duplizieren und von welchen du abhängst, die niemand mehr wartet.
Der Wert lag nie in einer einzelnen Tool-Notiz. Er liegt in der Tatsache, dass nichts, was du gesammelt hast, still und leise verrotten, sich still und leise duplizieren oder unbeaufsichtigt bleiben kann, ohne dass etwas das aufschreibt, wo du es tatsächlich sehen wirst.
Baue zuerst Durchlauf 1 auf. Lass ihn zwei oder drei Wochen laufen, bevor du Durchlauf 2 anfasst. Die Duplikat- und Upstream-Risiko-Durchläufe sind bei fünf Repositories nutzlos. Sie beginnen, sich irgendwo jenseits von zwanzig zu amortisieren.
Wenn du mehr solcher Aufschlüsselungen möchtest, ich veröffentliche alle paar Tage eine auf Telegram und X. Beide kostenlos.
Telegram – https://t.me/GipArcAI
