Claude Development (Deutsch)

Claude Entwicklung

Übersicht

Diese Skill besitzt die gesamte aufgabenweite Entwicklungssequenz in Claude Code: implementiere die angeforderte Änderung, führe ihre Checks aus und hole dann eine unabhängige Codex-Review ein, falls gewünscht, bevor die Auslieferung erfolgt. Sie gilt sowohl für Anfragen in natürlicher Sprache als auch für Arbeiten, die über eine andere Skill gestartet wurden. Dies ist eine anweisungsbasierte Orchestrierung; automatische Skill-Auswahl und -Abschluss sind keine vom Host erzwungenen Garantien.

Verwendung

Verwende /claude-development <aufgabe> oder wende es auf eine autorisierte Claude-Entwicklungsanfrage an, zum Beispiel: Behebe diesen Fehler und liefere die verifizierte Änderung aus. Füge deklarative Konfigurationsänderungen hinzu, selbst wenn sie kein TDD benötigen. Planung, Erklärung und Review allein autorisieren keine Implementierung.

Eine Implementierungsanfrage autorisiert die für das angeforderte Ergebnis notwendigen lokalen Korrekturen, einschließlich begrenzter Codex-Korrektur nachgewiesener Defekte in diesem Umfang. Strengere Benutzergrenzen bleiben erhalten. Commits, Pushs, PR-Veröffentlichung, Genehmigungen und Merges behalten ihre bestehenden Autorisierungsanforderungen. Andere Skills besitzen ihre spezialisierten Schritte; diese Skill besitzt, wann die Entwicklung endet.

Schritte

1. Aufgabe und Voraussetzungen festlegen. Lese Repository-Anweisungen, aktuellen Git-Status, relevante Quellen und ADRs. Identifiziere die Anforderungen, erlaubten Dateien, bestehenden Änderungen und die Überprüfungsgrenze. Kläre nur materielle Unbekannte mit requirements-clarification. Überprüfe, ob die erforderlichen Checks verfügbar sind. Wenn eine unabhängige Codex-Review angefordert wird, überprüfe code-review-fix und seine deklarierte Laufzeit vor dieser Phase. Lasse automatische Stop-Review-Gates deaktiviert; fehlende optionale Review-Werkzeuge blockieren weder die Implementierung noch die normale Auslieferung.
2. Den umschließenden Workflow respektieren. Für eine Linear-Aufgabe lass linear-start und linear-workflow die Berechtigung, den Branch, den Tracker und den PR-Status besitzen. Andere spezialisierte Workflows behalten ihre eigene Autorität und Grenzen. Wenn diese Aufgabe einen offenen PR repariert, verwende den autorisierten pr-fix-Workflow für Reparatur und unabhängige Review; starte keine parallele lokale Reparaturschleife. Gewöhnliche lokale Implementierung bleibt hier, auch wenn keine andere Skill aufgerufen wurde.
3. Das festgelegte Ergebnis implementieren. Unzusammenhängende Arbeiten erhalten. Wende tdd für eigenes ausführbares Verhalten und native oder bestehende Validierung für deklarative Änderungen an. Verwende die relevanten Domänen-Skills, ohne jeden Test, jeden Tool-Aufruf oder jede Teilaufgabe zu einer separaten Auslieferungsstufe zu machen. Zeichne die vollständige Aufgabenänderung und alle absichtlich ausgeschlossenen Änderungen auf.
4. Die relevanten Checks ausführen. Indiziere beabsichtigte neue Dateien vor Formatierung, Lint und Typprüfung. Führe die für die tatsächliche Änderung geeignete Repository-Barriere mit benannter Umgebung und Grenzen aus. Fehlgeschlagene Checks sind unvollendete Entwicklung, keine Erlaubnis, Behauptungen abzuschwächen. Behebe nur autorisierte Fehler und halte fehlende wesentliche Beweise explizit fest.
5. Angeforderte unabhängige Review einmal ausführen. Codex-Review ist optional; eine Implementierungsanfrage allein erfordert sie nicht. Wenn der Benutzer Review und begrenzte Korrekturen anfordert, aktiviere code-review-fix auf dem vollständigen lokalen Delta mit Anforderungen, Kandidatenidentität und rohen Check-Beweisen. Setze Claudes Schreibvorgänge aus, während der autorisierte Workflow läuft. Eine reine Review-Anfrage autorisiert keine Korrekturen und verwendet code-review. Starte keine der beiden Sequenzen innerhalb einer delegierten Korrektur neu. Wenn pr-fix Reparatur und Review besitzt, bewahre seinen Umfang, anstatt eine zweite Schleife zu erzeugen.
6. Das beobachtete Ergebnis ausliefern. Melde den finalen Kandidaten, geändertes Verhalten, Befunddispositionen, tatsächliche Checks, Umgebung und verbleibende Grenzen. Eine fehlende, veraltete oder unvollständige angeforderte Review bleibt eine explizite Grenze; eine nicht angeforderte Review ist keine Auslieferungsvoraussetzung. Sage nicht, dass die Entwicklung abgeschlossen ist, nur weil Code geschrieben wurde, Checks bestanden wurden, ein Kind zurückgegeben wurde oder eine Aufgabe als abgeschlossen markiert wurde. Bewahre alle bestehenden Veröffentlichungs- und Genehmigungs-Checkpoints im umschließenden Workflow.

Fallstricke

• Eine einfache Anfrage umgeht spezialisierte Skills — die Verifikation kann verschwinden; dieser Workflow gilt für Claude-Entwicklung unabhängig davon, wie die Aufgabe gestartet wurde.
• TDD wird zum äußeren Workflow — ein grüner Test beendet die Auslieferung zu früh; überprüfe die vollständige Aufgabe und führe jede angeforderte Review nach der Implementierung und den Checks durch.
• Jedes Kind startet die Abschlusssequenz — Reviews rekursieren und der Zähler für Durchläufe wird zurückgesetzt; nur der äußere Entwicklungsbesitzer ruft die finale Phase auf.
• Eine Konfigurationsänderung überspringt TDD — das Überspringen eines Wertetests kann auch versehentlich die Review überspringen; verwende native Validierung und führe eine unabhängige Review durch, wenn angefordert.
• Eine bestehende PR-Reparatur erhält eine zweite Schleife — konkurrierende Schreiber und Ergebnisse divergieren; behalte den pr-fix-Besitzer und seine finale unabhängige Review bei.

Einschränkungen

• Beginne niemals mit Implementierung, Reparatur oder Veröffentlichung auf Basis einer Planungs- oder Review-Anfrage.
• Melde niemals eine nicht durchgeführte Review als abgeschlossen oder erfordere eine nicht angeforderte Codex-Review.
• Überschreibe niemals Benutzergrenzen oder erweitere über das angeforderte Ergebnis und die bestätigten Korrekturen hinaus.
• Dupliziere niemals die code-review-fix- oder pr-fix-Schleife innerhalb einer delegierten Korrektur.
• Aktiviere niemals ein Stop-Review-Gate oder präsentiere eine automatische Skill-Auswahl als technisch erzwungen.
• Installiere niemals fehlende Laufzeiten oder ersetze fehlende Beweise durch ein erfolgreich aussehendes Ergebnis.