Eine wöchentliche Excel-Checkliste mit PowerShell, TypeScript und WSL automatisieren

PowerShell lohnt sich, weil es einen Haufen Klickerei unter Windows in ein paar Zeilen verwandelt. Rechnerinfos, Dienste, geplante Aufgaben: Schneller kommt man an nichts davon heran. Dazu kam der Wunsch herauszufinden, wie ein KI-Agent in echte Entwicklungsarbeit passt, nicht als App-Generator auf einen einzigen Prompt, sondern als Partner, mit dem man unbekannte APIs erkundet, Fehler durcharbeitet, einen Ansatz hinterfragt und iteriert. Fertig war ein Experiment, dem nur noch das Problem fehlte. Das tauchte dann ganz von selbst auf.

Eine Checkliste, die automatisiert werden wollte

Viele haben schon gedacht: "Ich sollte eine Excel-Checkliste führen." Das ist ein einfacher Weg, bei der Sache zu bleiben, etwa bei der Jobsuche. Dann kommt der zweite Gedanke. Wirst du sie wirklich jede Woche aktualisieren? Das heißt: offene Punkte in die nächste Woche übertragen, erledigte irgendwo ablegen, Daten ändern, die alte Woche sichern und das Ganze für immer wiederholen.

Solche Wiederholung löst einen bekannten Programmiererreflex aus: Das lässt sich doch sicher automatisieren. Wie schwer kann das schon sein?

Die Wahl des Stacks

Der erste Gedanke war PowerShell. Auf dem Rechner lief Windows, Excel war lokal installiert, die Aufgabenplanung gehört zum Betriebssystem, und PowerShell kann mit allen dreien reden.

Ein riesiges PowerShell-Skript war aber nicht verlockend. Ziel war etwas, das andere Entwickler lesen und erweitern können und auf dem sich später leicht aufbauen lässt. Da der Arbeitsalltag größtenteils aus JavaScript und TypeScript bestand, wurde TypeScript zum Gerüst des Projekts, und PowerShell übernahm nur die Windows-spezifischen Teile. Die Schichten sehen so aus:

TypeScript
    ↓
PowerShell
    ↓
Windows / Excel

TypeScript kümmert sich um Konfiguration und Orchestrierung. PowerShell erledigt, was es von Natur aus gut kann.

Ärger mit WSL-Pfaden

Entwickelt wurde in WSL, also läuft das Projekt unter Ubuntu, während die Excel-Datei unter Windows liegt. Das bringt Eigenheiten mit sich. Ein WSL-Pfad sieht so aus:

/mnt/c/Users/username/Documents/AutoTask/Weekly_Checklist.xlsx

Excel braucht dagegen die Windows-Form:

C:\Users\username\Documents\AutoTask\Weekly_Checklist.xlsx

Für genau diese Umwandlung bringt WSL wslpath mit. Aus TypeScript lässt sich der Pfad übersetzen, bevor er an PowerShell geht:

const windowsChecklist = execFileSync(
  'wslpath',
  ['-w', checklist],
  { encoding: 'utf8' },
).trim();

Das ist kurz, und jetzt übergibt die App auf der Linux-Seite PowerShell einen ordentlichen Windows-Pfad.

Excel Excel sein lassen

Der erste Versuch bearbeitete die .xlsx-Datei direkt mit einer JavaScript-Bibliothek. Technisch funktionierte das: Die Daten wanderten, die Arbeitsmappe ließ sich öffnen. Aber die Formatierung ging kaputt. Dropdowns, Stile und das Verhalten der Mappe, alles, was die Tabelle angenehm machte, wurde zu einem größeren Problem als das, das gelöst werden sollte.

Das führte zu einer zentralen Architekturentscheidung. Warum Excels Verhalten nachbauen, wenn Excel schon installiert ist? Lieber vereinfachen. PowerShell kann ein Excel-COM-Objekt erzeugen:

$excel = New-Object -ComObject Excel.Application

und dann die echte Desktop-Anwendung die Arbeitsmappe öffnen lassen:

$workbook = $excel.Workbooks.Open($checklist)

Damit bleibt die gesamte vorhandene Formatierung genau so, wie sie war.

Der wöchentliche Wechsel

Das Hauptskript heißt rollover.ts. Es nimmt die aktuelle Checkliste und macht sie für die nächste Woche fertig. Die Arbeitsmappe hat drei Blätter:

• This Week enthält die aktiven Aufgaben.
• Task History enthält die erledigten.
• Settings legt fest, etwa ob offene Aufgaben übernommen und ob Notizen behalten werden.

Beim Start liest das Skript das echte Systemdatum und ermittelt den aktuellen Zeitraum von Montag bis Sonntag. Das war wichtiger als gedacht. Eine frühe Version schob die Mappe bei jedem Lauf einfach eine Woche weiter. Klingt gut, bis man fünfzehnmal testet und merkt, dass man sich bis in den November automatisiert hat.

Die Lösung: Das Systemdatum wird zur maßgeblichen Quelle. Die Logik fragte nicht mehr, welche Woche in der Mappe steht plus sieben Tage, sondern welche Woche tatsächlich ist.

Damit war auch ein Problem mit der Spalte Weeks Carried gelöst. Eine offene Aufgabe soll nicht eine zusätzliche übertragene Woche bekommen, nur weil das Skript gelaufen ist. Statt hochzuzählen, berechnet der Code deshalb die Wochen zwischen dem ursprünglichen Übertragungsdatum der Aufgabe und der tatsächlichen aktuellen Woche. Die Operation ist jetzt idempotent: Mehrere Läufe in derselben Woche liefern jedes Mal dasselbe Ergebnis. Viel besser.

Die alte Woche archivieren

Bevor sich etwas ändert, wird die Arbeitsmappe in einen Ordner Previous Weeks kopiert, unter einem Namen, der den Zeitraum der Woche abdeckt:

2026-09-07_to_2026-09-13.xlsx

Dieses Archiv ist eine vollständige Kopie der Datei vor dem Wechsel, mit erledigten und offenen Aufgaben genau so, wie sie standen. Dann wird die aktive Mappe aktualisiert. Erledigte Aufgaben landen in Task History, die neuesten oben. Offene Aufgaben bleiben in der aktiven Liste, wenn die Übernahme eingeschaltet ist. Die Daten der neuen Woche werden eingetragen, und Excel speichert.

Den Planer planen

Ein Wechselskript muss man trotzdem im Kopf behalten und ausführen, was den Sinn zunichtemacht. Hier kommt configure.ts ins Spiel. Das Blatt Settings speichert einen Wechseltag, standardmäßig Montag. Das Konfigurationsskript öffnet die Mappe, liest diesen Wert und registriert per PowerShell eine geplante Windows-Aufgabe.

Die Aufgabe nutzt außerdem die Option StartWhenAvailable. Ist der Wechsel für Montag 8:00 Uhr fällig und der Rechner aus, führt Windows ihn aus, sobald die Maschine wieder verfügbar ist. Die Tabelle pflegt sich jetzt selbst.

Wo der KI-Agent geholfen hat

Der KI-Agent sollte nicht aus einer einzigen Anfrage eine automatisierte Excel-Checkliste bauen, deren Ergebnis man ungeprüft übernimmt. Er war am ganzen Prozess beteiligt. Der Rhythmus sah so aus:

I define behavior
      ↓
AI suggests implementation
      ↓
I run it
      ↓
Something explodes
      ↓
We inspect the actual error
      ↓
Check documentation
      ↓
Fix it
      ↓
Run it again

Was, genau besehen, ziemlich nach normaler Softwareentwicklung klingt. Am nützlichsten war der Agent jenseits der Alltagstechnologien. PowerShell und TypeScript waren vertraut, aber Excels COM-Automatisierung hat ihre eigenen Merkwürdigkeiten. Werte zwischen Zellen zu kopieren verhält sich unterschiedlich, je nachdem, ob man .Value2 direkt zuweist oder Excels eigenes Copy() und PasteSpecial() verwendet. Datumswerte bringen eine weitere Ebene, denn Excel speichert sie als fortlaufende Zahlen, während PowerShell eigene .NET-Typen hat. Und alles überquert Grenzen, von Node in WSL zu PowerShell unter Windows und schließlich per COM in Excel. Zeitweise sah der Stack ungefähr so aus:

TypeScript
→ Node
→ WSL
→ PowerShell
→ COM
→ Excel
→ Why is this a System.Double?

Gut funktionierte es, die genaue Fehlermeldung einzufügen, eine Vermutung zur Ursache zu erklären und dann mit dem Agenten die passende Microsoft-Dokumentation zu finden. Am wichtigsten blieb, jede Antwort zu testen. Mehr als einmal verhielt sich ein Vorschlag, der auf dem Papier vernünftig aussah, anders, sobald Excel ins Spiel kam.

Das ist die zentrale Lehre über KI in der Entwicklung: Sie verkürzt den Weg von „das weiß ich noch nicht“ zu „ich weiß, was ich testen muss“. Sie beschleunigt Lernen und Durchlaufzeit, wenn man ein solides Architekturbild hat. Das ist etwas ganz anderes, als generiertem Code blind zu vertrauen.

Die eigene Erfahrung lenkt weiter

Vorhandenes technisches Wissen zahlte sich immer wieder aus:

• Wer PowerShell kennt, sieht leicht, wo PowerShell ins Design gehört.
• Wer TypeScript kennt, dem war klar, dass die Windows-Automatisierung nicht die ganze Anwendung steuern sollte.
• Das Verständnis geplanter Aufgaben zeigte, dass kein dauerhaft laufender Node-Prozess nötig war.
• Zu erkennen, wann eine Lösung absurd kompliziert wird, war vielleicht die wertvollste Fähigkeit von allen.

An mehreren Stellen begann die Implementierung, um Probleme herumzuwachsen, statt sie zu lösen. Dann war es besser, den Agenten zu lenken, Ideen abzulehnen und ihn zu einem vernünftigen Ansatz zurückzuführen, als ihn das Projekt diktieren zu lassen.

Was Nutzer sehen

Aus Nutzersicht ist der Ablauf schlicht. Man nutzt die Excel-Checkliste wie gewohnt: Aufgaben anlegen, Prioritäten setzen, Fälligkeiten eintragen, Erledigtes abhaken. Wenn die Woche wechselt, wandert eine Kopie der alten Mappe in den Ordner Previous Weeks, erledigte Aufgaben ziehen auf den Reiter Task History um, und offene Aufgaben fließen in die Mappe der neuen Woche.

Alles bleibt lokal. Keine Datenbank, kein Server, kein Abo, nichts läuft im Hintergrund. Die beweglichen Teile sind Excel, TypeScript, PowerShell, WSL und die Windows-Aufgabenplanung. Zugegeben, ziemlich viel Technik für eine wöchentliche Checkliste, aber um die Größe ging es nicht. Es ging darum, eine wiederkehrende Pflicht zu nehmen, Werkzeuge einzusetzen, die man schon versteht, und die unbekannten Teile als Gelegenheit zum Lernen zu sehen. PowerShell lieferte den Ausgangspunkt, der KI-Agent öffnete einen neuen Zugang zu den unbekannten Teilen, und aus einer langweiligen kleinen Checkliste wurde ein überraschend interessantes Automatisierungsprojekt. Nicht schlecht für etwas, das mit dem Gedanken begann, dass sich das wohl automatisieren ließe.