Zurück zur Übersicht
Claude & Codex Artikel 08 von 08

Wiederholbare Workflows mit Projektregeln

Der Abschluss der Claude/Codex-Reihe: Kontextdateien, Regeln und feste Prüfabläufe für stabile KI-Coding-Workflows.

Hier baust du wiederholbare Claude-Code- und Codex-Workflows, damit KI-Coding im Alltag kontrolliert statt zufällig läuft. Du kennst die Grundlagen, hast beide Tools eingerichtet und weißt wann du welches einsetzt. Jetzt geht es darum, die Arbeit mit ihnen effizienter zu machen. Nicht mehr Aufwand, sondern bessere Ergebnisse mit weniger Erklärungsbedarf.

CLAUDE.md: Projektkontext dauerhaft hinterlegen

Jedes Mal neu erklären was dein Projekt macht und welche Konventionen gelten kostet Zeit. Claude Code löst das mit einer Datei namens CLAUDE.md im Projektverzeichnis. Diese Datei liest Claude automatisch beim Start.

# CLAUDE.md — Projektkontext ## Projekt Python-Webanwendung mit Flask. PostgreSQL als Datenbank. ## Konventionen - Funktionen auf Englisch benennen - Docstrings bei allen öffentlichen Funktionen - Fehler immer loggen bevor sie weitergeworfen werden ## Wichtige Dateien - app.py — Einstiegspunkt - models/ — Datenbankmodelle - routes/ — API-Endpunkte

Mit einer solchen Datei musst du Claude nicht mehr bei jedem Start erklären womit du arbeitest. Es kennt den Kontext von Anfang an.

Wiederholbare Aufgaben als Vorlage

Wenn du regelmäßig die gleichen Arten von Aufgaben stellst, lohnt es sich, deine besten Prompts zu notieren. Nicht als starre Schablone, sondern als Ausgangspunkt den du schnell anpassen kannst.

Ich habe zum Beispiel Standardformulierungen für: neue Funktion mit Tests, Refactoring einer bestehenden Datei, Erklärung eines unbekannten Code-Teils. Das spart Zeit und führt zu konsistenteren Ergebnissen.

Praktische Setup-Tipps

📁
CLAUDE.md pro Projekt
Jedes Projekt bekommt seine eigene Kontextdatei. Je spezifischer, desto besser die Ergebnisse.
🔑
API-Keys in .env
Zugangsdaten immer in einer .env-Datei, niemals direkt im Code. Und .env immer in der .gitignore.
🌿
Git-Branch pro Aufgabe
Für größere KI-unterstützte Änderungen einen eigenen Branch anlegen. Einfacher zu prüfen, einfacher rückgängig zu machen.
📝
Prompts dokumentieren
Was gut funktioniert hat, notieren. Nicht im Tool, sondern in einer eigenen Datei. Wissen das du aufgebaut hast.

Wie ich heute arbeite

Nach einigen Monaten ist der Workflow für mich selbstverständlich geworden. Ich öffne ein Projekt, Claude kennt den Kontext, ich stelle eine Aufgabe und prüfe das Ergebnis. Was früher Stunden dauerte, dauert jetzt Minuten.

Das liegt nicht daran dass die Tools magisch sind. Sondern daran dass ich gelernt habe wie ich mit ihnen arbeite: klare Aufgaben, Kontext vorab, jedes Ergebnis prüfen. Das ist der Unterschied zwischen jemandem der ein Werkzeug benutzt und jemandem der es beherrscht.

Meine ehrliche Einschätzung

Diese Tools haben meine Produktivität verdoppelt. Nicht weil sie alles können, sondern weil ich weiß was sie können und was nicht. Wer das versteht, hat einen echten Vorteil, unabhängig vom Erfahrungslevel.

Das war die Artikelreihe
Von der Entscheidung welches Tool, über Einrichtung und sichere Arbeitsweise bis zu fortgeschrittenen Tipps. Was du daraus machst liegt bei dir. Wenn du Fragen hast oder zeigen willst was du gebaut hast, schreib mir.
Newsletter abonnieren

Der nächste sinnvolle Schritt

Wenn du diesen Teil verstanden hast, passen diese Seiten als Nächstes:

Häufige Fragen

Was gehört in Projektregeln?

Projektstruktur, Testbefehle, Stilregeln, Sicherheitsgrenzen, Review-Erwartungen und Hinweise zu generierten Dateien.

Was macht Prompts wiederholbar?

Klare Rollen, konkretes Ziel, betroffene Dateien, Akzeptanzkriterien und feste Prüfungen nach der Änderung.

Wie passt das ins Team?

Teams brauchen gemeinsame Regeln für Datenschutz, Review, Commit-Grenzen, Toolfreigaben und Verantwortung für KI-Änderungen.