In diesem Artikel zeige ich euch, wie ich mit Claude Code Software entwickle. Bevor der Agent programmiert, schreibe ich mit ihm eine Spezifikation. Aus ihr entstehen Arbeitspakete, und jedes Paket läuft durch eine feste Kette aus Konzeption, Umsetzung, Test und Review, bis am Ende ein geprüfter Pull Request steht.

Den Ablauf habe ich mir als eigene Skills und Subagents für Claude Code gebaut. Er besteht aus drei Phasen, /spec, /spec-plan und /spec-run, dazu kommen zwei Hilfen für Bugfixes und für ganze Meilensteine.

Warum zuerst eine Spezifikation?

Nach meiner Erfahrung setzt ein Agent sehr zuverlässig um, was man ihm sagt. Er füllt aber auch jede Lücke in der Anforderung mit einer eigenen Annahme, und die sieht meistens plausibel aus. Fällt so eine Annahme erst im fertigen Code auf, ist sie teuer.

Deshalb steht bei mir am Anfang immer eine schriftliche Spezifikation. Sie ist die einzige verbindliche Quelle für alle späteren Schritte. Was dort fehlt oder unklar ist, pflanzt sich durch den ganzen Prozess fort. Gründlichkeit ist an dieser Stelle wichtiger als Tempo.

Planungssession mit /spec

Mit /spec starte ich eine Planungssession. Zuerst prüft der Skill, ob das Vorhaben überhaupt eine Spezifikation braucht. Ein kleiner, klar umrissener Bugfix braucht keine, dafür gibt es /spec-fix, dazu weiter unten mehr.

Danach folgt ein Interview. Claude Code fragt nach, statt anzunehmen: Was genau soll passieren, welche Randfälle gibt es, was ist ausdrücklich nicht Teil des Vorhabens? Am Ende liegt eine versionierte Datei .specs/<feature>/spec.md im Repository. Erst wenn ich sie freigegeben habe, geht es weiter.

Meilensteine und Arbeitspakete mit /spec-plan

Im nächsten Schritt leitet /spec-plan aus der Spezifikation Meilensteine und Arbeitspakete ab. Jedes Paket bekommt eine eigene Paket-Spec. Sie ist der komplette, bindende Arbeitsauftrag für die spätere Umsetzung, einschließlich Testplan und einer klaren Grenze, was nicht zum Paket gehört.

Zusätzlich vergibt der Skill jedem Paket eine Komplexitätsklasse: mechanisch, normal oder schwierig. Nach meiner Freigabe legt ein eigener Agent die Meilensteine und Pakete als Milestones und Issues auf der Plattform an, bei mir GitHub oder Forgejo.

Der Loop pro Issue mit /spec-run

Jetzt kommt der eigentliche Kern. /spec-run nimmt sich genau ein Issue vor und führt es durch spezialisierte Subagents. Der Orchestrator selbst schreibt keinen Produktivcode, er versorgt die Agenten mit Kontext, bewertet ihre Rückmeldungen und kümmert sich um Git und die Plattform.

Der Ablauf sieht so aus:

Ablauf von der Spezifikation über die Paket-Specs bis zum Loop je Issue mit Konzeption, Umsetzung sowie Test und Code-Review bis zum Merge; bei Befunden geht es zurück in die Umsetzung
Spec-driven Development mit den drei Phasen.

Die einzelnen Rollen:

  • architect: schreibt aus Paket-Spec und bestehendem Code ein Umsetzungskonzept.
  • concept-reviewer: prüft das Konzept gegen die Spezifikation, bevor eine Zeile Code entsteht. Eine Konzeptlücke kostet hier eine Textrunde statt einer Umsetzungsrunde.
  • implementer: setzt das freigegebene Konzept um, ohne den Umfang zu erweitern.
  • tester: schreibt und erweitert die Tests nach den Akzeptanzkriterien und führt die Testsuite aus.
  • reviewer: prüft den Diff auf Korrektheit, Randfälle, Sicherheit und die Konventionen des Projekts.

Tester und Reviewer laufen parallel. Melden sie Befunde, geht es in eine Fix-Runde zurück zur Umsetzung. Erst wenn beide Gates grün sind, entsteht der Pull Request mit Merge und Abgleich des Status.

Modellwahl und Ablauf richten sich nach der Komplexitätsklasse. Bei einem mechanischen Paket entfällt die Konzeptphase, der implementer arbeitet direkt gegen die Paket-Spec. Stolpert so ein Paket, wird die Konzeptphase nachgeholt. An einer Stelle spare ich bewusst nie: Die beiden Review-Gates laufen immer auf dem stärksten Modell. Ein schwächeres Review findet nach meiner Erfahrung weniger und meldet dann einfach „Freigegeben“.

Kleine Bugfixes mit /spec-fix

Nicht jede Änderung braucht eine Planungssession. Für echte Bugfixes, die in ein Arbeitspaket passen und deren Umfang direkt ersichtlich ist, gibt es /spec-fix. Statt einer Spezifikation dokumentiert der Skill den Fehler strukturiert im Issue. Diese Doku ist dann die bindende Vorgabe für /spec-run. Ist der Umfang größer oder unklar, verweist der Skill zurück an /spec.

Ganze Meilensteine mit /spec-chain

Falls ein ganzer Meilenstein am Stück abgearbeitet werden soll, nutze ich /spec-chain. Der Skill ruft /spec-run seriell für mehrere Issues auf, jeweils in einem frischen Prozess. Beim ersten Fehlschlag oder der ersten Rückfrage hält die Kette an. So kann ein Meilenstein unbeaufsichtigt laufen, ohne dass sich ein Fehler durch die folgenden Pakete zieht.

Fachwissen für die Agenten

Damit ein Agent auch bei Informatica-Themen verlässlich arbeitet, braucht er belastbares Fachwissen. Dafür habe ich eigene Skills gebaut, die Claude Code bei Bedarf lädt:

  • IDMC-REST-API: gegen echte Orgs verifiziertes Wissen zu Authentifizierung, Export und Import, Migration Service, Publish und Metering, mit Fallstricken und Referenz-Clients.
  • IDMC-Design-Objekte: Aufbau von Mappings, Mapping Tasks und Taskflows, Bearbeitung außerhalb der Oberfläche und Offline-Validierung.
  • IDMC-Konnektoren: eine Landkarte der Konnektorhandbücher mit Merkmalen, Verbindungskonfiguration und dokumentierten Fallstricken.
  • Informatica PowerCenter: Objektmodell und Export-XML, gegen echte Exporte verifiziert, dazu die Kommandozeilen-Werkzeuge pmrep, pmcmd und infacmd.

So muss der Agent nicht raten, wie ein Endpunkt heißt oder wie ein Export aufgebaut ist.

Wofür ich das einsetze

Mit diesem Ablauf entstehen meine eigenen Werkzeuge rund um IDMC, alle in Python. Ein Deployment-Tool übernimmt die automatisierte Promotion von IDMC-Assets über die REST-API: Export, Import, Umzug zwischen Projekten über den Migration Service, Umstellung von Connections und Runtime Environments und Publish von Taskflows. Ein Metering-Tool exportiert und wertet den Lizenzverbrauch aus. Derzeit entsteht außerdem ein webbasierter Laufzeit-Monitor für IDMC mit einem Gantt-Chart über Job- und Taskflow-Läufe, wie ihn der PowerCenter Workflow Monitor hatte.

Quellen

Ich hoffe, dass ich euch mit diesem Einblick in meine Arbeitsweise weiterhelfen konnte. Falls ihr Fragen dazu habt oder selbst mit Claude Code strukturierter arbeiten wollt, schreibt mir gerne.