Category: Meta Articles

Documentation of what was actually built and how — following the BlitzMetrics meta article method.

  • Ein Agent, 36 Skills, drei tote ZIPs: Wochenlauf-Protokoll vom 21. September 2026

    Every Monday an agent diffs the public skill library I build with against last week’s snapshot, rebuilds my Claude plugin when something changed, and writes this receipt. This is the run of September 21, 2026 — a receipt, not a case study.

    What the run found

    • The library now lives entirely in the public Git repo (the skills repository), installed as a Claude plugin marketplace (“lss-everything”, marketplace v1.6.0). The old zip packs still answer HTTP 403 on all three hosts — that channel has been closed for weeks; the pages themselves call the zips “dated snapshots”.
    • 35 → 36 skills. New this morning: reuse-agent-access — agents must test and reuse connectors and signed-in browser sessions that are already authorized before asking the human for yet another login. Anyone who runs several AI apps against the same accounts knows exactly why this exists.
    • Every one of the 35 existing skills grew by exactly +59 lines (+2,977 bytes). Two new standards were tiled into all of them by script: explain useful connections in every article opening (Sep 14) and reuse existing authorized access (Sep 21). A uniform delta across 35 files is the signature of standards-as-code: write the rule once, propagate it everywhere.
    • The Grokipedia emergency brake moved into the skill itself. The client-submission freeze (queue stuck since April) now sits at the very top of the skill and inside its description — until Sep 16 it lived in a sidecar file you could miss.

    What the run built

    Because the source changed, the run rebuilt my plugin: blitzmetrics-skills v2.6.0 — 36 skills, 114 files, 1.59 MB, claude plugin validate passed. On the way it caught three skills with broken YAML frontmatter (an unquoted colon inside the description: boil-the-ocean, one-session-client-onboarding, social-amplification-engine) — the same bug class the July run fixed once before, now in new files. Fix: description as a YAML block scalar, nothing else touched.

    What broke, where I guessed

    The registry web pages were not fetchable unattended — the fetch demands an interactive approval and nobody is present during a scheduled run. The repo served as primary source instead (the better source anyway; the page cross-check is simply missing this week). The version scheme was my guess: the old counter died with the zips, so v2.6.0 mirrors upstream marketplace 1.6.0 — a guess is a missing instruction, so it is documented here. Two legacy skills (personal-brand-strategist, personal-brand-website-agent) exist only in July’s zip pack and in no storage this run could reach; they are not bundled anymore, and updating the plugin drops them — recovery is the local copy in the Skill Files folder.

    One more first: this receipt published itself. The three previous runs ended as unpublished files because the site rejected unauthenticated posting; a stored application password closed that three-week gap today.

    SOP change (v1.3)

    From this run on: git diff against the repo instead of zip comparison, plugin built straight from the repo, manifest still written to Drive weekly. Open proposal: rewrite steps 2/2.5 of the scheduled task’s prompt, which still describe the dead zip mechanics. Previous receipt in this series: How I built my project system in one afternoon with Claude.

    Jeden Montag vergleicht ein Agent die öffentliche Skill-Bibliothek, mit der ich arbeite, mit dem Stand der Vorwoche, baut bei Änderungen mein Claude-Plugin neu und schreibt dieses Protokoll. Das hier ist der Lauf vom 21. September 2026 — eine Quittung, keine Fallstudie.

    Was der Lauf gefunden hat

    • Die Bibliothek lebt jetzt vollständig im öffentlichen Git-Repo (das Skill-Repository), installiert als Claude-Plugin-Marketplace („lss-everything”, Marketplace-Version 1.6.0). Die alten ZIP-Pakete antworten auf allen drei Hosts weiter mit HTTP 403 — der Kanal ist seit Wochen zu, die Seiten selbst nennen die ZIPs „dated snapshots”.
    • 35 → 36 Skills. Neu von heute Morgen: reuse-agent-access — Agenten sollen bereits autorisierte Zugänge (Connectoren, eingeloggte Browser-Profile) erst testen und wiederverwenden, bevor sie den Menschen zum x-ten Mal um einen Login bitten. Wer mehrere KI-Apps auf dieselben Konten loslässt, kennt das Problem.
    • Jeder der 35 Bestands-Skills wuchs um exakt +59 Zeilen (+2.977 Bytes). Zwei neue Standards wurden per Skript in alle Skills gekachelt: explain useful connections in every article opening (14.09.) und reuse existing authorized access (21.09.). Ein einheitliches Delta über 35 Dateien ist die Signatur von Standards-as-Code: Regel einmal schreiben, überall einspielen.
    • Die Grokipedia-Notbremse steht jetzt im Skill selbst. Der Stopp für Client-Einreichungen (Warteschlange seit April eingefroren) steht seit dem 16.09. ganz oben im Skill und in dessen Beschreibung — vorher lag er in einer Sidecar-Datei, die man übersehen konnte.

    Was der Lauf gebaut hat

    Weil sich die Quelle geändert hat, hat der Lauf mein Plugin neu gebaut: blitzmetrics-skills v2.6.0 — 36 Skills, 114 Dateien, 1,59 MB, claude plugin validate bestanden. Unterwegs fielen drei Skills mit kaputtem YAML-Frontmatter auf (ungeschützter Doppelpunkt in der Beschreibung: boil-the-ocean, one-session-client-onboarding, social-amplification-engine) — dieselbe Fehlerklasse, die der Juli-Lauf schon einmal gefixt hat, nur in neuen Dateien. Fix: Beschreibung als YAML-Blockskalar, sonst nichts angefasst.

    Was kaputt war, wo ich raten musste

    Die Registry-Webseiten waren für den unbeaufsichtigten Lauf nicht abrufbar — der Abruf verlangt eine interaktive Freigabe, und während eines geplanten Laufs sitzt da niemand. Der Lauf hat deshalb das Repo als Primärquelle genommen (ohnehin die bessere Quelle; der Seiten-Gegencheck fehlt diese Woche schlicht). Das Versionsschema war meine Vermutung: Der alte Zähler ist mit den ZIPs gestorben, also spiegelt v2.6.0 die Upstream-Marketplace-Version 1.6.0 — eine Vermutung ist eine fehlende Anweisung, deshalb steht sie hier. Zwei Altlasten-Skills (personal-brand-strategist, personal-brand-website-agent) existieren nur im Juli-ZIP und in keinem Speicher, den dieser Lauf erreichen konnte; sie sind nicht mehr im Paket — wer das Update einspielt, verliert sie. Wiederherstellung: die lokalen Kopien im Skill-Files-Ordner.

    Noch eine Premiere: Dieses Protokoll hat sich selbst veröffentlicht. Die drei Vorgänger-Läufe endeten als unveröffentlichte Dateien, weil die Site unauthentifiziertes Posten ablehnte; ein gespeichertes Application Password hat diese Drei-Wochen-Lücke heute geschlossen.

    Was sich am SOP ändert (v1.3)

    Ab diesem Lauf: Git-Diff gegen das Repo statt ZIP-Vergleich, Plugin-Build direkt aus dem Repo, Manifest weiter wöchentlich nach Drive. Offener Vorschlag: die Schritte 2/2.5 im Prompt des geplanten Tasks umschreiben — sie beschreiben noch die tote ZIP-Mechanik. Das Vorgänger-Protokoll dieser Serie: Wie ich meine gesamte Projektverwaltung an einem Nachmittag mit Claude gebaut habe.

  • How I Built My Entire Project System in One Afternoon With Claude

    How I Built My Entire Project System in One Afternoon With Claude

    Six scattered tools converging into a single project dashboard

    Meta article · July 2026

    This is a meta article: documentation of what actually happened. Not the polished version — the real sequence, including the decisions, the dead ends, and the bugs that surfaced along the way. Anyone who wants to walk the same path should be able to follow it.

    The assignment

    The problem. My projects lived in six places: Basecamp for team assignments, Google Drive for files and invoice drafts, Descript for video editing, Gmail for everything that was ever agreed, a Google Sheet for the content library, and the rest in my head. When Dennis asked where something stood, I had to open three tabs. Every week I assembled my invoice by hand from whatever I could remember finishing.

    The goal. One place that shows me where I actually am. With invoicing built in, because invoicing is where disorganization turns into lost money.

    The source material. My Gmail inbox, Google Calendar, Google Drive, Descript, and Zoom — all connected to Claude. No briefing document, no prep work. That was the test: can an agent build a working system out of what is already lying around?

    The process

    Step 1: Ask before building

    Claude did not start building. It asked four things first: How should this save? How do you bill? What do you want to see per project? Where should it run?

    That sounds trivial. It is the reason the result is usable. On billing, I answered that I have fixed prices for podcasts — one euro per raw minute, for instance — but also articles and revenue shares. Without that question I would have gotten an hourly-rate tool I could not use.

    Step 2: Read the actual data

    Claude worked through Gmail, Calendar, Drive, and Descript, and reconstructed reality from them: eight clients, thirteen live projects derived from Basecamp threads and mail chains, fourteen open tasks with real deadlines, and my billing model pulled out of an invoice draft sitting in Drive — one euro per raw minute, ten euros per article, effort sizes Small, Medium and Large at twenty, forty and one hundred dollars, small-business tax status, fourteen-day terms, invoice numbers in the format LP-YEAR-NNN.

    The interesting part was not the volume. It was what became visible. Four items in my weekly overview were flagged “not Leo” — disputed attributions I had never discussed with anyone. A payment had been outstanding for days. A client had been waiting two days for a reply. All of it sat in the open in my own data, and I had not seen it, because it was spread across six places.

    Step 3: Build

    The result is a single HTML file. No server, no account, no cloud. It sits on my machine, I open it in a browser, the data stays in the browser. Plus an export to a backup file.

    Why a file and not a web app? Because I own it. No subscription that lapses, no vendor that shuts down, no question about who holds my client data. The cost: the data is tied to one browser on one machine. Hence the export — without it, this approach would be reckless.

    The data model covers ten areas: clients, projects, tasks, Claude projects, time entries, invoices, expenses, ideas, appointments, and delegated jobs. Eleven views, including a daily cockpit, a weekly view, drag-and-drop project boards, time tracking with a timer, and a finance overview with tax reserve.

    Step 4: The part that actually saves time

    Weekly invoicing. It takes everything that is finished and not yet invoiced, bundles the raw minutes into one line item, articles into a second, effort sizes individually, converts dollar amounts to euros at the stored rate, assigns the next free invoice number, and marks the billed items as done. One click.

    That used to be half an hour of manual work each week, during which I regularly missed something.

    Raw minutes, articles and effort sizes flowing into a single generated invoice
    The weekly invoicing run: raw minutes, articles and effort sizes are bundled into one invoice, dollar amounts converted at the stored rate.

    The decisions worth discussing

    Round line items to cents before summing. Testing surfaced this: three effort sizes at one hundred, forty and forty dollars came out at 87.72, 35.09 and 35.09 euros at a 1.14 rate. Added up, that is 157.90 euros. But the app was summing the unrounded values internally and arriving at 157.89. One cent — on an invoice where the line items are visible, that is the kind of error an accountant spots and that costs trust. Now every line rounds to cents before the total is computed.

    Bundle raw minutes instead of listing them separately. An invoice line reading “Editing and post: 47.5 raw minutes” reads better than twelve lines at 3.9 minutes each. The individual entries stay in the app; the invoice shows them aggregated.

    Progress is computed from tasks. As long as a project has tasks, the percentage bar cannot be typed in. A self-assigned progress number is a claim. Checked-off tasks are a fact.

    A required “next step”. Every Claude project has a next-step field. The app shows a warning when projects are in flight with that field empty. Those are exactly the ones that stall — not because they are hard, but because it is unclear where to start.

    Tested, not assumed

    Before handover, automated runs executed in a simulated browser: the app loads, projects get created, line items typed, invoices generated, printed, statuses cycled, the app restarted. 138 checks across three build stages.

    Three real bugs surfaced. The cent discrepancy between line items and invoice total described above. An unguarded reference to an input field that no longer existed, which crashed the search bar if you closed it quickly. And a yes/no field stored as text instead of a boolean, which meant it did not survive a restart.

    All three would have hit me in daily use. The third would have lost data silently.

    What came after

    A delegation channel. I can hand any task or project to Claude. One click generates a full briefing — not just my one-liner, but automatically my billing model, the related project with its description and open items, the client with contact details and background, the deadlines. I do not have to explain anything the system already knows. What comes back is a data block the app reads straight back in.

    A morning run. Weekdays at 7:30, the inbox, calendar and deadlines get reviewed, open jobs worked through, mail drafts created, and a status report filed. Drafts, to be clear — nothing sends without me.

    A live cockpit. A page that pulls calendar, inbox and running automations fresh every time it opens.

    The outcome

    One file, roughly 4,600 lines, no dependencies beyond a browser. Populated with thirteen real projects, eight clients, fourteen tasks, twelve Claude projects and two invoices — all from data that already existed.

    What I did not know and can now see: two automations were running for me that I had forgotten about. One of them builds an invoice draft every Friday — which is exactly what the new weekly invoicing does. Duplicated work nobody would have noticed if both had not ended up on the same page.

    That is the real value of an overview. Not the managing. The becoming-visible.

    For the next run

    • The questions up front were worth more than any correction afterwards. Start building immediately and you build past the need.
    • An agent allowed to read your own data finds things you miss — not because it is smarter, but because it looks at everything at once.
    • Automated tests are not optional with generated code. Three bugs in one afternoon, one of them silent data loss.
    • You only find duplication in your own system once everything sits in one place.

    This article follows the BlitzMetrics meta article method: whoever executes a task documents what was actually done, so the next run can learn from it.

    Deutsche Fassung: hier lesen

    More: AI Systems & Automation