Gentleman-Programming/gentle-ai-work-unit-commits

Wann verwenden

Laden Sie diese Skill, wenn entschieden werden soll, was in jeden Commit oder PR gehört.

Verwenden Sie sie für:

• Aufteilen einer Funktion in überprüfbare Arbeitseinheiten.
• Vorbereiten von Commits vor dem Öffnen eines PRs.
• Umwandeln einer großen Änderung in verkettete oder gestapelte PRs.
• Halten der kognitiven Last für Reviewer gering.
• Anwenden von SDD-Aufgaben, ohne versehentlich einen PR mit mehr als 400 geänderten Zeilen zu erzeugen.

Kritische Regeln

Regel	Anforderung
Commit nach Arbeitseinheit	Ein Commit repräsentiert eine auslieferbare Verhaltensänderung, Fehlerbehebung, Migration oder Dokumentationseinheit.
Nicht nach Dateityp committen	Vermeiden Sie models, dann services, dann tests, wenn keines allein funktioniert.
Tests mit Code halten	Tests gehören in denselben Commit wie das Verhalten, das sie überprüfen.
Dokumentation mit der sichtbaren Änderung halten	Dokumentation gehört zu der Funktion oder dem Workflow, den sie erklärt.
Eine Geschichte erzählen	Ein Reviewer sollte anhand des Diffs und der Commit-Nachricht verstehen, warum jeder Commit existiert.
Bereit für zukünftige PRs	Jeder Commit sollte ein Kandidat für einen verketteten PR sein, wenn die Änderung wächst.
SDD-Arbeitslastschutz	Wenn SDD-Aufgaben eine Änderung von >400 Zeilen vorhersagen, gruppieren Sie Commits vor der Implementierung in verkettete PR-Abschnitte.
Budget ist kein Code-Golf	Verkleinern Sie niemals einen Diff, indem Sie Kommentare, Leerzeilen, Dokumentation oder Tests löschen oder Code komprimieren, um das Review-Budget zu erreichen (Standard 400 oder das Sitzungs-review_budget_lines). Teilen Sie nach Arbeitseinheit auf oder melden Sie die Überschreitung.

Checkliste für Arbeitseinheiten

Vor dem Commit bestätigen:

• Der Commit hat einen klaren Zweck.
• Das Repository ergibt nach Anwendung nur dieses Commits noch Sinn.
• Tests oder Dokumentation für diese Einheit sind enthalten, sofern relevant.
• Ein Rollback ist ohne Rückgängigmachen unabhängiger Arbeiten sinnvoll.
• Die Commit-Nachricht erklärt das Ergebnis, nicht die Dateiliste.

Beispiele für Aufteilungen

Schwache Aufteilung	Bessere Arbeitseinheiten-Aufteilung
models hinzufügen	feat(auth): Token-Validierungs-Domain-Modell und Tests hinzufügen
services hinzufügen	feat(auth): Token-Validierung in den Login-Flow einbinden
tests hinzufügen	Tests sind in jedem Verhaltens-Commit enthalten
dokumentation aktualisieren	Dokumentation ist in dem benutzersichtbaren Commit enthalten, den sie erklärt

PR-Beziehung

Verwenden Sie Arbeitseinheiten-Commits als Grundlage für verkettete PRs:

1. Bauen Sie die kleinste unabhängige Arbeitseinheit.
2. Fügen Sie die Überprüfung für diese Einheit hinzu.
3. Committen Sie sie mit einer Conventional Commit-Nachricht.
4. Wenn der PR sich 400 geänderten Zeilen nähert, fördern Sie Commits oder Gruppen von Commits zu verketteten PRs.

SDD-Beziehung

Wenn sdd-tasks eine Review-Arbeitslastprognose erstellt:

• Geringes Risiko: Arbeitseinheiten-Commits in einem PR belassen.
• Mittleres Risiko: Nach Arbeitseinheit committen und vor PR-Erstellung die geänderten Zeilen überwachen.
• Hohes Risiko: Der delivery_strategy von SDD folgen – bei ask-on-risk nachfragen, bei auto-chain automatisch aufteilen, bei übermäßigem single-pr eine size:exception verlangen, bei exception-ok eine akzeptierte size:exception aufzeichnen.
• Die Aufteilung ist begrenzt: Nach einem ehrlichen Aufteilungsschritt, falls keine kohärente Arbeitseinheiten-Aufteilung das Budget einhält, anhalten und die kleinste ehrliche Anzahl mit einer size:exception-Empfehlung melden. Nicht iterieren, um den Code zu verkleinern, um die Anzahl zu erreichen.

Jede SDD-Arbeitseinheit sollte sauber auf einen Commit oder PR abbilden mit:

• klarem Startzustand,
• klarem Endzustand,
• Überprüfung in derselben Einheit,
• Rollback, das keine unabhängigen Arbeiten entfernt.

Befehle

# Überprüfen Sie die Geschichte vor dem Commit
git diff --stat
git diff --cached --stat

# Überprüfen Sie den Style der letzten Commits
git log --oneline -5