Smithers: dauerhafte, zurückspulbare Ausführungen für Coding-Agenten

Eine Laufzeit für Agentenarbeit, die die Sitzung überlebt

Das README positioniert Smithers als dauerhafte Laufzeit für Coding-Agenten-Arbeit: für Fälle, in denen ein Agent über viele Schritte ein echtes Repository bearbeitet und die Arbeit prüfbar, genehmigbar und wiederherstellbar sein muss. Das Kernversprechen ist, dass jeder Schritt einer Ausführung eine Datenbankzeile ist, wodurch Live-Beobachtung, Zurückspulen und Wiedergeben eingebaut sind und nicht nachgerüstet werden. Eine Ausführung kann von jedem früheren Stand geforkt werden, um eine alternative Timeline abzuzweigen. Das README zieht die Grenze ausdrücklich: Für eine einzelne Antwort aus einem Prompt soll man das Modell direkt aufrufen; Smithers ist für mehrstufige Repository-Änderungen, menschliche Genehmigungen, Review-Schleifen und Absturzwiederherstellung gedacht.

Erstellung durch Prompts, nicht von Hand

Das README sagt, dass Benutzer Workflows nie von Hand schreiben. Beschreibe das gewünschte Ergebnis in einfachem Englisch, und der Coding-Agent baut den Workflow aus denselben Primitiven, die das integrierte Paket verwendet. Der Prompt ist der Erstellungsschritt. Die Einrichtung erfolgt mit `bunx smthrs init` innerhalb eines Projekts: Es installiert die smithers-Fähigkeit in erkannte Coding-Agenten und legt ein `.smithers/`-Verzeichnis mit den Erstellungsworkflows an. Das README legt nicht fest, welche Agenten automatisch erkannt werden, abgesehen von Claude Code und Pi als Beispielen, und listet auch nicht das vollständige Installationsverhalten auf; diese Details bleiben der Dokumentationswebsite überlassen.

Dauerhaftigkeit als Unterscheidungsmerkmal

Das README nennt Dauerhaftigkeit das Unterscheidungsmerkmal. Jeder abgeschlossene Schritt wird in dem Moment, in dem er endet, in SQLite gespeichert. Die Laufzeitschleife ist: Workflow rendern, Aufgabe ausführen, Ausgabe gegen ein Schema validieren, in SQLite speichern, aus dem gespeicherten Zustand neu rendern, um die nächste Aufgabe zu bestimmen. Ein Absturz setzt vom letzten Schreibvorgang fort, die unterbrochene Aufgabe läuft als neuer Versuch erneut, und abgeschlossene Aufgaben werden übersprungen. Genehmigungen, menschliche Rückfragen, Wiederholungen und Wiedergabe sind in diesem Modell erstklassig. Das README sagt auch, dass Ausführungen unzuverlässige Tools überleben, gibt aber keine Details dazu, wie Tool-Fehler klassifiziert oder erneut versucht werden.

Workflows sind JSX-Bäume von Aufgaben

Ein Workflow ist ein JSX-Baum von Aufgaben. Das Beispiel im README zeigt eine Schleife, die sich wiederholt, bis ein Reviewer zustimmt, mit einem Codier-Agenten, einem schreibgeschützten Reviewer-Agenten, maximal fünf Iterationen und schemavalidierter Ausgabe. Der Beispielcode referenziert Modellnamen wie gpt-5.6-luna und gpt-5.6-sol, die das README nicht als Produktionsmodelle ausweist. Das README merkt an, dass Benutzer diese Dateien normalerweise nicht von Hand schreiben, da der Agent sie erzeugt, aber das Format ist versionierbar, überprüfbar und wieder ausführbar, was den Kontrast zur flüchtigen Subagenten-Fan-out bildet.

Keine Wette auf einen Anbieter oder ein Modell

Das README sagt, Smithers setze nicht auf ein Labor oder einen Anbieter. Aufgaben können auf Claude Code, Codex, Cursor, Pi, Antigravity oder jedes AI-SDK-Modell zeigen, und mehrere können in einem Workflow gemischt werden. Dasselbe Sandbox-Primitiv führt einen Agenten lokal über Bubblewrap, Docker oder Microsandbox aus oder über jedes Backend, das SandboxProvider implementiert. Das README sagt außerdem, dass `bunx smthrs mcp add` den MCP-Server in Cursor, Copilot, Hermes, OpenClaw und rund 20 weitere Coding-Agenten einbindet, listet sie aber nicht auf.

Ausführungen von der CLI aus beobachten und steuern

Die mitgelieferten Workflows laufen direkt über die CLI. Das README nennt `bunx smthrs ps` zum Auflisten aktiver, pausierter und kürzlich abgeschlossener Ausführungen, `inspect` für Schritte, Agenten, Genehmigungen und Ausgaben einer Ausführung, `logs` zum Verfolgen des Ereignisprotokolls, `chat` zum Lesen der Chat-Ausgabe des Agenten und `monitor` zum Öffnen einer Live-Seite mit gruppierter Ausführungsliste und Status pro Knoten. Zur Laufsteuerung gehören `up` mit einem `--resume`-Flag, `rewind` zu einem früheren Stand, `fork` und `replay`. Das README sagt, dass diese Befehle existieren und was sie tun, dokumentiert aber nicht ihre vollständigen Optionssätze.

Was im Paket enthalten ist

`init` installiert ein fokussiertes Paket mit drei Erstellungsworkflows: create-workflow, create-skill und docs-driven-development; frühere Starter bleiben unter examples/init-pack/ erhalten. Der Ordner examples enthält über 100 ausführbare Workflows, die Review-Schleifen, parallele Ticket-Flotten, Supervisoren, Debatten, Migrationen und mehr abdecken. Vom README genannte Kontrollfunktionen: Genehmigungen, die riskante Schritte absichern, Sandbox-Isolation, Prometheus-Metriken und OpenTelemetry-Traces ab Werk mit einem lokalen Grafana-Stack per Einzelbefehl, Evaluations-Suiten mit GEPA-artiger Prompt-Optimierung, Cross-Run-Speicher in lokalem SQLite mit optionalem Hindsight-Abruf nach Bedeutung sowie Hot Reload von Prompts, Konfiguration oder JSX während der Ausführung. Das Repository ist MIT-lizenziert, Copyright 2025 William Cory; die Lizenz gewährt Nutzung, Kopie, Änderung, Zusammenführung, Veröffentlichung, Verteilung, Unterlizenzierung und Verkauf und besagt, dass die Software ohne Gewährleistung bereitgestellt wird. Der Lizenztext sagt nichts über Support, Sicherheitsgarantien oder Wartungszusagen aus.

Redaktionelles Fazit

Smithers schreibt jeden abgeschlossenen Schritt in SQLite, rendert den Workflow aus diesem Zustand neu und überlässt die Workflow-Erstellung dem Coding-Agenten selbst. Das README zieht eine klare Grenze: Es ist für mehrstufige Repository-Änderungen, Genehmigungen, Review-Schleifen und Absturzwiederherstellung gedacht, nicht für einzelne Prompt-Antworten.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes