chshzh/charlie-claude

Git-Commit-Workflow

Kritische Regeln

1. Vor dem Committen prüfen: Führe immer git diff . aus, um den vollständigen Arbeitsbaum zu überprüfen, bevor Commits vorgeschlagen oder erstellt werden.
2. Erst planen, dann committen: Lege einen Commit-Plan vor (gruppierte Dateien, Begründung, vorgeschlagene Nachrichten) und warte auf die explizite Zustimmung des Benutzers, bevor git commit ausgeführt wird.
3. Nach logischen Änderungen aufteilen: Trenne Commits nach Zuständigkeitsbereichen – vermische keine unzusammenhängenden Fehlerbehebungen, Refactorings, Dokumentationen, reine Formatierungsänderungen oder generierte Dateien, es sei denn, der Benutzer fordert dies ausdrücklich an.
4. Keine interaktiven Befehle: Verwende nur nicht-interaktive Git-Befehle.
5. Niemals Annahmen treffen: Behandle jede Aufforderung zum "Committen von Änderungen" als Erlaubnis zur Prüfung und Planung, nicht als Erlaubnis zur Ausführung von git commit.

Workflow

Schritt 1 – Den Arbeitsbaum prüfen

git diff .
git status --short
git diff --cached   # nur wenn bereits gestaffte Änderungen existieren

Schritt 2 – Einen Commit-Plan vorschlagen

Präsentiere eine Tabelle oder Liste mit:

• Gruppe: die Dateien für jeden vorgeschlagenen Commit
• Begründung: warum diese Dateien zusammengehören
• Vorgeschlagene Commit-Nachricht: verwende den korrekten Stil für das Repository (siehe Commit-Nachrichten-Formate unten)

Schritt 3 – Auf Zustimmung warten

Nach der Präsentation des Plans verwende das AskQuestion-Werkzeug, um die Zustimmung einzuholen. Biete immer diese Optionen an:

Question: "Mit diesem Commit-Plan fortfahren?"
Options:
  - "Zustimmen – wie geplant committen"
  - "Commit-Nachrichten zuerst bearbeiten"
  - "Commits neu gruppieren"
  - "Abbrechen"

Führe git commit erst aus, wenn der Benutzer Zustimmen auswählt. Behandle jede andere Auswahl als Aufforderung zur Überarbeitung des Plans.

Schritt 4 – Genehmigte Commits ausführen

Staffe für jeden genehmigten Commit nur die relevanten Dateien und committe:

git add <datei1> <datei2> ...
git commit -s -m "typ(bereich): kurzbeschreibung"

Verwende bei Bedarf einen HEREDOC für mehrzeilige Nachrichten:

git commit -s -m "$(cat <<'EOF'
typ(bereich): kurze zusammenfassung

- detail zeile 1
- detail zeile 2
EOF
)"

Commit-Nachrichten-Formate

Repo-Typ zuerst erkennen

Repo	Stil
Benutzer-App-Repo (eigenes Projekt)	Conventional Commits
zephyr/, nrf/, nrfxlib/, modules/	Zephyr-Stil

Benutzer-App-Repos – Conventional Commits

typ(bereich): kurze zusammenfassung

Häufige Typen: feat, fix, refactor, docs, chore, test, style, build. Titel ≤ 72 Zeichen. Textkörper optional, aber hilfreich bei nicht-trivialen Änderungen.

NCS-/Zephyr-Repos – Zephyr-Stil

[nrf tag] bereich: unterbereich: kurze zusammenfassung

Textkörper, der erklärt, was, warum, Annahmen und wie es verifiziert wurde.

Upstream PR #: NNNNN          (wenn aus Upstream portiert)
Ref: NCSDK-XXXXX              (wenn ein internes Ticket verfolgt wird)
Assisted-by: Claude:claude-sonnet-4.6   (wenn KI-Unterstützung erfolgte)
Signed-off-by: Vollständiger Name <email>

• Titel ≤ 72 Zeichen; Textkörper ist erforderlich (nicht leer) für jegliche Upstream-Beiträge
• Textkörper-Zeilen ≤ 75 Zeichen
• Signed-off-by: erforderlich (DCO) – verwende git commit -s
• NRF-Präfix-Tags: [nrf fromlist] (an Upstream), [nrf fromtree] (aus Upstream), [nrf noup] (nur NCS), [nrf ncsdk] (nur SDK)
• Füge Assisted-by: hinzu, wenn KI wesentlichen Code geschrieben hat

Beispiele:

[nrf fromlist] drivers: nrf_wifi: WPA3-AUTO-Sicherheitstyp hinzufügen

Der wpa_supplicant benötigt einen dedizierten key_mgmt-Enum-Wert für
WPA3-AUTO-Modus. Ohne diesen schlagen Stationen, die sowohl WPA2 als auch
WPA3 ankündigen, beim Schlüsselaustausch fehl.

Upstream PR #: 106674
Signed-off-by: Dein Name <[email protected]>

[nrf noup] tests: my_module: Komponententest für Null-Längen-Puffer hinzufügen

Testet den Grenzfall, bei dem die Länge des Eingabepuffers gleich Null ist,
was zuvor eine Zusicherungsverletzung im Parser auslöste.

Ref: NCSDK-12345
Signed-off-by: Dein Name <[email protected]>

Gruppierungsrichtlinien

Änderungstyp	Separater Commit?
Neuer Feature-Code	Ja
Fehlerbehebung	Ja
Refactoring (keine Verhaltensänderung)	Ja
Konfigurations-/Kconfig-Änderungen	Ja (oder mit zugehörigem Feature)
Dokumentation / README	Ja (sofern nicht eng mit einem Feature verbunden)
Nur Formatierung / Leerzeichen	Ja
Generierte / automatisch aktualisierte Dateien	Ja
Board-Overlay + zugehöriges prj.conf	Können zusammen gruppiert werden
Sysbuild-Dateien	Nach logischem Zweck gruppieren

NCS-spezifische Hinweise

Dateigruppierung:

• prj.conf, boards/*.conf, overlay-*.conf – mit dem Feature gruppieren, das sie aktivieren
• CMakeLists.txt-Änderungen – separater Commit, es sei denn, sie sind trivial Teil einer Feature-Erweiterung
• west.yml-Änderungen – immer ein separater Commit mit klarer Begründung
• sysbuild/-Dateien – nach logischem Zweck gruppieren (z.B. mcuboot-Konfigurationsänderungen zusammen)
• Generierte Partition-Manager-Dateien (pm/, *.map) – separater chore-Commit oder weglassen, wenn nicht sinnvoll

In NCS-/Zephyr-Repos (zephyr/, nrf/, nrfxlib/):

• Zephyr-Stil verwenden (siehe oben), nicht Conventional Commits
• Immer einen nicht-leeren Textkörper einfügen – CI wird leere Textkörper für Upstream-PRs ablehnen
• Führe git log -- <datei> aus, um zu sehen, wie andere Commits für dasselbe Subsystem formatiert haben

Änderungen innerhalb einer einzelnen Datei aufteilen

Wenn eine Datei zwei oder mehr logisch unterschiedliche Änderungen enthält, die in separate Commits gehören (z.B. eine Fehlerbehebung + ein neuer Richtlinienabschnitt), teile sie ohne interaktives Staging auf:

1. Entferne den späteren Abschnitt vorübergehend aus der Datei (Python oder StrReplace)
2. Staffe und committe die erste Änderung
3. Stelle den entfernten Abschnitt wieder her
4. Staffe und committe die zweite Änderung

MARKER = "\n## Selbstaktualisierungsrichtlinie\n"
text = path.read_text()
path.write_text(text[:text.find(MARKER)])  # späteren Abschnitt entfernen
# → git add + commit "fix: ..."
path.write_text(text)                      # vollständigen Inhalt wiederherstellen
# → git add + commit "feat: ..."

Warum: git log -p <datei> zeigt dann jede logische Änderung in ihrem eigenen Commit – einfacher zu bisectieren, zu überprüfen oder rückgängig zu machen.

Fallstrick: Stelle immer sicher, dass der Marker vor den schließenden Zeilen der Funktion/des Blocks liegt. Wenn der Marker die letzte Anweisung in einer Funktion ist, fehlen in der entfernten Datei return und }, was zu Fehlern wie expected declaration or statement at end of input führt.

Selbstaktualisierungsrichtlinie

Überprüfe am Ende jeder Konversation, was entdeckt wurde, und ob Fakten in diesem Skill neu, korrigiert oder veraltet sind (z.B. neue Gruppierungsmuster, NCS-spezifische Dateikonventionen, Commit-Nachrichten-Konventionen).

Falls Aktualisierungen gerechtfertigt sind:

1. Sammle alle vorgeschlagenen Änderungen mit einer kurzen Begründung für jede.
2. Präsentiere eine Zusammenfassung für den Benutzer und bitte um Zustimmung mit AskQuestion.
3. Wende genehmigte Aktualisierungen sofort auf diese Datei an.

Ändere diesen Skill nicht während einer laufenden Konversation, es sei denn, der Benutzer fordert dies ausdrücklich an.