analog-watch

Dieses Projekt ist keine Uhr. Es ist ein Experiment.... ..

Die analoge Uhr ist das Ergebnis — aber das eigentliche Thema ist die Methode, mit der sie entstanden ist.

---

Das Konzept: Issue-getriebene KI-Orchestrierung

Das Projekt demonstriert, wie man Claude (KI) ausschließlich über Git-Issues orchestriert, ohne direkte Eingaben während der Entwicklung zu machen. Der Ablauf war simpel:

1. Ein Forgejo-Repository anlegen
2. Claude mit einem autonomen Loop starten (/loop 30s)
3. Issues schreiben — Claude arbeitet sie selbstständig ab

Claude lief im Hintergrund und prüfte jede Minute, ob es offene Issues gibt. Wenn ja: Code schreiben, committen, pushen, Issue kommentieren, Issue schließen. Wenn nein: schlafen, wieder prüfen.

Der Entwickler hat nie eine Zeile Code geschrieben. Die gesamte Kommunikation lief über Issues.

---

Ablauf dieses Demo-Runs

Issue	Titel	Ergebnis
#1	Analoge Uhr in HTML/JS	Canvas-Uhr mit Zeigern und Zifferblatt
#2	Geschwindigkeit der Zeit einstellen	Slider + Input für Zeitfaktor (−3× bis +3×)
#3	Geschwindigkeit stufenlos bis 5000	Logarithmischer Slider, Zahlen-Input, ±5000×
#4	Bewegter Hintergrund (mehrfach erweitert)	4 Muster: Sterne, Gitter, Wellen, Partikel-Netz mit Spiralen & FBM-Noise
#5	Hintergrund an Zeitgeschwindigkeit koppeln	Muster frieren bei 0 ein, laufen rückwärts bei negativem Faktor
#6	DAX-Börsenticker (mehrfach erweitert)	Scrollender Ticker, Yahoo Finance, an Zeitfaktor gekoppelt
#7	News des Tages	Tagesschau-Panel links der Uhr, RSS via rss2json
#8	Kleines Klavier	Web Audio API, 2 Oktaven, Maus + Tastatur

Erweiterungen kamen über Kommentare in bestehenden Issues — Claude erkannte neue Anforderungen im Kommentarverlauf und setzte sie um.

---

Warum das interessant ist

Issues als universelles Task-Interface

Git-Issues sind ein bereits bekanntes, strukturiertes Format. Jeder weiß wie man ein Issue schreibt. Damit wird der Mensch zum Produktmanager, der Anforderungen formuliert — und die KI zum autonomen Entwickler, der sie umsetzt.

Keine speziellen Prompt-Formate. Keine API-Integrationen. Nur ein Issue-Tracker, den es ohnehin schon gibt.

Asynchrones Arbeiten

Der Mensch muss nicht anwesend sein, wenn Claude arbeitet. Issues können tagsüber geschrieben werden — Claude arbeitet sie nachts ab. Das entkoppelt Anforderungserstellung von Implementierung.

Nachvollziehbarkeit

Jede Änderung ist in Git, jede Entscheidung ist im Issue-Kommentar dokumentiert. Das Ergebnis ist vollständig auditierbar — wer hat was wann beauftragt, und was hat Claude konkret geändert.

---

Potenzielle Verbesserungen

Kurzfristig

• Labels als Routing: Issues mit Label agent:frontend gehen an einen Frontend-Agenten, agent:backend an einen Backend-Agenten — mehrere spezialisierte Agenten parallel
• Prioritäten: Label P0 lässt Claude sofort reagieren (kürzeres Poll-Intervall), P2 wird gebündelt abgearbeitet
• Issue-Templates: Strukturierte Vorlagen erzwingen vollständige Anforderungen (Akzeptanzkriterien, Testfälle, Abhängigkeiten)
• Automatische Tests: Claude schreibt nach jeder Implementierung Tests und führt sie aus — schlägt der Test fehl, bleibt das Issue offen

Mittelfristig

• Multi-Agent-Setup: Ein Architekt-Agent zerlegt große Issues in Teilaufgaben und verteilt sie als Sub-Issues an Spezialist-Agenten
• Review-Agent: Ein zweiter Agent reviewed den Code des ersten und kommentiert im PR — erst nach Approval wird gemergt
• Kontext-Akkumulation: Ein dediziertes CONTEXT.md im Repo hält Architekturentscheidungen fest, die jeder Agent beim Start liest
• Dependency-Tracking: Issues können andere Issues als Abhängigkeit referenzieren — Claude wartet, bis Voraussetzungen erfüllt sind

Langfristig

• Bidirektionale Kommunikation: Claude eröffnet selbst Issues wenn es auf Probleme stößt, Unklarheiten entdeckt oder Refactoring-Bedarf sieht
• Stakeholder-Benachrichtigung: Claude postet nach einem abgeschlossenen Feature-Bundle eine Zusammenfassung in einen Slack-Channel oder per Mail
• Kontinuierliche Qualitätssicherung: Ein permanent laufender QA-Agent prüft neu eingecheckten Code gegen definierte Standards und öffnet automatisch Issues bei Verstößen
• Cross-Repo-Agenten: Ein Agent koordiniert Änderungen über mehrere Repositories hinweg (z.B. API-Änderung + Client-Update + Dokumentation synchron)

---

Lessons Learned aus diesem Demo-Run

• Issues als Kommentare erweitern funktioniert gut — Claude erkennt neue Anforderungen im Kommentarverlauf zuverlässig
• Zu vage Anforderungen führen zu korrekter, aber nicht gewünschter Implementierung — präzise Issues sind wertvoller als schnelle
• Das Poll-Intervall (hier: 1 Minute) ist der einzige Engpass zwischen Anforderung und Ergebnis
• Kein menschliches Review ist riskant bei echten Projekten — ein Review-Gate vor dem Merge ist empfehlenswert
• Kosten: Dieser gesamte Demo-Run kostete wenige Cent — die Methode skaliert wirtschaftlich

---

Setup reproduzieren

# 1. Forgejo-Repo klonen
git clone git@forgejo.zahl1.de:stefan/analog-watch.git

# 2. Claude Code starten
claude

# 3. Autonomen Loop starten
/loop 30s

# 4. Issues schreiben — Claude erledigt den Rest

Der API-Token wird in forgejo-zahl1.api-token erwartet (nicht im Repo).

---

Gebaut mit Claude Code · Orchestriert via Forgejo Issues · Kein manueller Code