Überspringt Research/Planung/Plan-Review und startet direkt aus einer Plandatei in plans/. Unterstützt Issue-Nummern und Dateinamen als Argument. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
3.3 KiB
description: Implementiert ein Teil-Issue direkt aus einem bestehenden Implementierungsplan — überspringt Research, Planung und Plan-Review. Aktivieren wenn bereits ein vollständiger Plan in plans/ existiert und die Implementierung beginnen soll. Argument: Issue-Nummer (z.B. #44) oder Plan-Dateiname. Nicht verwenden wenn noch kein Plan existiert (dann /story nutzen). model: claude-sonnet-4-6
/implement — Implementierung aus bestehendem Plan
Überspringt Research, Planung und Plan-Review. Liest den Plan und implementiert direkt. Warte nach Phase 4 auf Bestätigung vor Phase 5–7.
Vorab: Repository-Check
git rev-parse --show-toplevel
Scheitert der Befehl: Abbruch. Meldung:
"Kein Git-Repository gefunden.
/implementläuft nur innerhalb eines Git-Repos."
Phase 1: Plan und Schnellstart-Sektion laden
Argument aus ARGUMENTS auswerten:
- Issue-Nummer (z.B.
#44,44): suche inplans/nach einer Datei die diesen Begriff enthält - Dateiname (z.B.
plans/mein-plan.md): lies direkt - Leer: liste alle Dateien in
plans/und frage den User
ls plans/
Lies die Plandatei vollständig. Suche dann den Abschnitt ### Schnellstart #<issue> (oder den passenden Abschnitt wenn kein Issue angegeben).
Aus der Schnellstart-Sektion extrahieren:
- Branch-Name → für Schritt 2
- "Zuerst lesen"-Liste → für Schritt 3
- "Implementieren"-Zeile → welche Plan-Phasen umzusetzen sind
- "PR schließt"-Zeile → für den PR-Body
Phase 2: Branch anlegen
Prüfe den aktuellen Branch:
git branch --show-current
Falls auf main oder falschem Branch: Branch anlegen wie im Schnellstart angegeben:
git checkout -b <branch-name-aus-schnellstart>
Falls der Branch bereits existiert: Wechsel dorthin.
Phase 3: Kritische Dateien laden
Lies die in der Schnellstart-Sektion genannten Dateien in der angegebenen Reihenfolge. Maximal 8 Dateien — nicht mehr, auch wenn der Plan weitere nennt.
Phase 4: Implementierung
Implementiere die im Plan beschriebene Phase Schritt für Schritt:
- Phasen-Schritte der Reihe nach abarbeiten
- Nach jedem logischen Abschnitt committen (mindestens alle 30 Minuten)
- CLAUDE.md-Konventionen einhalten: Ruff, Type Hints, async, Pydantic-Schemas, Logging statt print
- Keine generischen
try/except, kein toter Code - Alembic-Migration:
alembic revision --autogenerate -m "<beschreibung>"falls nötig
Bei unerwarteten Problemen: User informieren, konkreten Lösungsvorschlag präsentieren, nicht stumm abweichen.
Nach Abschluss der Implementierung: Melde dem User kurz was fertig ist. Warte auf Bestätigung bevor Phase 5 startet.
Phase 5: Tests und PR
Rufe /go auf (test-runner → code-simplifier → PR in Gitea).
Im PR-Body:
closes #<issue>aus der Schnellstart-Sektion- Akzeptanzkriterien aus dem Plan-Abschnitt als Checkboxen
Warte auf die PR-URL.
Phase 6: Security-Audit
Starte den security-audit-Agenten für alle in dieser Session geänderten Dateien.
- Bei kritischen Befunden: Beheben, dann erneut prüfen
- Bei Warnungen: Mit User abstimmen
Phase 7: Abschluss
Rufe /ship auf (PR mergen → Branch löschen → main pullen).
Abschlussmeldung:
- PR-URL
- Implementiertes Issue (#XX)
- Nächstes Issue aus der Schnellstart-Sektion (falls vorhanden), damit der User die nächste Session starten kann